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A plurality of digital services (V' r V' N . and A' r A' N 0 are carried in a multiplex data stream (162) to a plurality of re- 
mote locations. The multiplex data stream (162) comprises a continuous sequence of frames (156). Each frame (156) com- 
prises two consecutive fields, and each field comprises a plurality of lines. A first group of the lines in each field defines a 
transport layer region of that field, and a second group of the lines defines a service data region. Portions of the service data 
region of each field are allocated to respective ones of the video services in proportion to respective data rates of each ser- 
vice. A multiplex control packet is generated (104) for each field that specifies, for each service, which portion of the service 
data region is allocated to that service. A multiplex map (104) is transmitted with each field, and therefore, the number and 
location of packets may be dynamically adjusted on a per field basis. 



FOR THE PURPOSES OF INFORMATION ONLY 

Codes used to identify States party to the PCT on the front pages of pamphlets publishing international 
applications under the PCT. 



AT 


Austria 


CB 


United Kingdom 


MR 


Mauritania 


AU 


Australia 


GE 


Georgia 


MW 


Malawi 


BB 


Barbados 


CN 


Guinea 


NE 


Niger 


BE 


Belgium 


CR 


Greece 


NL 


Netherlands 


BF 


Burkina Faso 


HU 


Hungary 


NO 


Norway 


BC 


Bulgaria 


IE 


Ireland 


NZ 


New Zealand 


BJ 


Benin 


IT 


Italy 


PL 


Poland 


BR 


Brazil 


JP 


Japan 


FT 


Portugal 


BY 


Belarus 


KE 


Kenya 


RO 


Romania 


CA 


Canada 


KG 


Kyrgystan 


RU 


Russian Federation 


CF 


Central African Republic 


KP 


Democratic People's Republic 


SD 


Sudan 


CC 


Congo 




of Korea 


SE 


Sweden 


CH 


Switzerland 


KR 


Republic of Korea 


SI 


Slovenia 


CI 


Cote d*l voire 


KZ 


Kazakhstan 


SK 


Slovakia 


CM 


Cameroon 


LI 


Liechtenstein 


SN 


Senegal 


CN 


China 


LK 


Sri Lanka 


TO 


Chad 


cs 


Czechoslovakia 


LU 


Luxembourg 


TC 


Togo 


cz 


Czech Republic 


LV 


Latvia 


TJ 


Tajikistan 


DE 


Germany 


MC 


Monaco 


TT 


Trinidad and Tobago 


DK 


Denmark 


MD 


Republic of Moldova 


UA 


Ukraine 


ES 


Spain 


MC 


Madagascar 


US 


United States of America 


Fl 


Finland 


ML 


Mali 


LIZ 


U/.bekistan 


FR 


France 


MN 


Mongolia 


VN 


Viet Nam 


CA 


Gabon 











><wo 



9410775A1 I > 



WO 94/1 0775 PCT/US93/10491 



A Multiplex Control Packet for Digital Services 

Field of the Invention 

The present invention relates generally to digital 
5 signal transmission, and more particularly, to a system for 
and method of multiplexing a plurality of digital services 
for transmission to a plurality of remote locations. 

Background of the Invention 

The background of the present invention is 

10 described herein in the context of subscription television 
systems, such as cable television and direct broadcast 
satellite (DBS) systems, that distribute a variety of program 
services to subscribers, but the invention is by no means 
limited thereto except as expressly set forth in the 

15 accompanying claims. 

In the subscription television industry, 
"programmers " produce "programs" for distribution to various 
remote locations. A "program" may consist of video, audio 
and other related services, such as closed- captioning and 

2 0 teletext services. A single programmer may wish to supply 
many programs and services. Typically, a programmer will 
supply these services via satellite to individual subscribers 
(i.e., DBS subscribers) and/or cable television operators. 
In the case of cable television operators, the services 

25 transmitted via satellite are received at the operator's 

"cable head-end" installations. A cable operator typically 
receives programs and other services from many programmers 
and then selects the programs/services it wishes to 
distribute to its subscribers. In addition, a cable operator 
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may insert locally produced services at the cable-head end. 
The selected services and locally produced services are then 
transmitted to the individual subscribers via a coaxial cable 

distribution network. In the case of DBS subscribers , each 
5 subscriber is capable of receiving a satellite down-link from 

the programmers directly. 

In the past, subscription television systems, 

including cable and DBS systems, have operated in the analog 

domain. Recently, however, the subscription television 
10 industry has begun to move toward all digital systems wherein 

prior to transmission, all analog signals are converted to 

digital signals. Digital signal transmission offers the 

advantage that digital data can be processed at both the 

transmission and reception ends to improve picture quality. 
15 In addition, digital data compression techniques have been 

developed that achieve high signal compression ratios. 

Digital compression allows a larger number of individual 

services to be transmitted within a fixed bandwidth. 

Bandwidth limitations are imposed by both satellite 
20 transponders and coaxial cable distribution networks, and 

therefore, digital compression is extremely advantageous. 
Several problems and concerns arise when one 

considers an all digital program services delivery system. 

First, there are a wide range of digital service rates in use 
25 throughout the industry. For example, digital video service 

rates differ from digital audio service rates . Digital video 

rates themselves can range from 17 Mbps (High Definition 

Television - HDTV) to as low as 1.544 Mbps 

(telecommunications standard Tl) . A problem arises when a 
30 source programmer wants to transmit multiple digital services 
having different data rates. There is a need, therefore, for 
a system that can accommodate different service data rates. 

Second, many digital compression algorithms produce 
a single compressed data stream that has a dynamically 
35 varying data rate. Most often this occurs because certain 
portions of the original data are redundant and the 
compression algorithm need only transmit a small amount of 
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data to represent those redundant portions. For example, in 
a sequence of video frames, the "scene" may not change 
significantly from frame to frame. Rather than transmit a 
redundant frame, a short code can be transmitted in its place 
5 indicating that the frame is substantially the same as the 
previously transmitted frame. During a typical television 
program, there are periods where scenes change rapidly (e.g., 
during an action sequence) and periods where scenes are 
relatively constant (e.g., during an interview). 
10 Consequently, the rate of compressed data will vary 

dynamically throughout the program. When multiplexing a 
plurality of compressed digital video services into a single 
multiplexed data stream having a fixed overall data rate, it 
is desirable to dynamically allocate portions of the overall 
15 data stream to the various video services depending on the 
individual data rate of each service at given times. This 
method of dynamic allocation is know as statistical 
multiplexing. Statistical multiplexing ensures a more 
efficient use of system bandwidth. Because video and audio 
20 compression will be used widely in the subscription 

television industry, it is desirable for any method of 
transmitting multiple compressed services to support 
statistical multiplexing . 

Another problem that arises in the subscription 
25 television industry context is that system requirements 

differ from programmer-to-programmer and cable operator-to- 
cable operator. Also, the requirements of individual 
programmers and cable operators change over time . For 
example, a programmer may initially determine that it wants 
30 to provide five video services. Later, that programmer may 
want to expand its offerings and provide additional video 
services. Having to replace system hardware, however, is 
undesirable. A system that allows programmers and cable 
. operators to expand the number and type of services they 
3 5 provide without major hardware changes or upgrades is 
desirable . 
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The present invention provides a system and method 
of transmitting multiple digital services, including video, 
audio, closed-captioning and teletext services, that 
satisfies the needs described above." 

5 Summary of the Invention 

Briefly stated, the present invention is directed 
to a method and system for multiplexing a plurality of 
digital services for transmission to a plurality of remote 
locations. According to the invention, digital services to 

10 be transmitted are provided to an encoder that generates a 
multiplex data stream which carries the services to the 
remote locations via a transmission medium, such as a 
satellite or a cable distribution network. The multiplex 
data stream generated by the encoder comprises a continuous 

15 sequence of frames. Each frame comprises two fields, and 
each field comprises a plurality of lines. The first group 
of the lines of each field defines a transport layer region 
of that field, and a second group of the lines defines a 
service data region. In accordance with the method of the 

20 present invention, portions of the service data region of 
each field are allocated to respective ones of the digital 
services in proportion to respective data rates of each 
service. A multiplex control packet is generated that 
specifies which portion of the service data region is 

25 allocated to each service. The multiplex control packet, is 
inserted into the transport layer region of each field. In 
addition to the multiplex control packet, a plurality of 
system data packets containing other system related 
information are also inserted into the transport layer region 

30 of each field. 

In accordance with an important feature of the 
present invention, a multiplex map is generated that 
specifies at least the size of the transport layer region and 
the location of individual packets within the transport layer 

3 5 region. With the multiplex map, therefore, the contents and 
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arrangement of the packets within the transport layer may be 
dynamically varied on a per field basis. 

The multiplex data stream generated by the encoder 
is then transmitted to a plurality of remote locations. Each 
5 of the remote locations is provided with a decoder for 
receiving a multiplex data stream and extracting selected 
services therefrom. Video services, for example, may be 
extracted from the multiplex data stream and displayed on a 
display device at the remote location. In greater detail, 
10 the decoder receives successive fields of the multiplex data 
stream. and, for each field, extracts the multiplex map from 
the field to determine the content of the transport layer 
region of that field. With the multiplex map, the decoder is 
able to extract the system data packets and the multiplex 
15 control packet from the transport layer region. In response 
to a user service selection, the decoder examines the 
multiplex control packet for each field to determine which 
portion of the service data region of that field is allocated 
to the selected service . Once the correct portion has been 
20 identified, the decoder is able to extract the selected 
service data from that field. 

In accordance with another aspect of the present 
invention, the overall data transmission rate of a multiplex 
data stream is related to the frequency of an analog video 
25 format used to produce analog video signals for display at a 
remote location. In particular, the lines of each field of 
the multiplex data stream are transmitted at a rate equal to 
the horizontal line frequency of the particular analog video 
format being used at the remote locations . In the case of 
3 0 NTSC, for example, the lines of each field of the multiplex 
data stream are transmitted at a rate of 15.743 kHz. In 
addition, the number of lines in a frame of the multiplex 
data stream is equal to the number of lines in a 
corresponding frame of the analog video format being employed 
35 at the remote locations. In the case of NTSC, for example, 
the number of lines in a frame is 525. When PAL video is 
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being employed at the remote locations, the number of lines 
in each frame of the multiplex data stream is 625. 

Further details and features of the present 
invention will become evident hereinafter. 

5 Brief Description of the Drawings 

The foregoing summary, as well as the following 
detailed description, is better understood when read in 
conjunction with the appended drawings. For the purpose of 
illustrating the invention, there is shown in the drawings 
10 embodiments that are presently preferred, it being 

understood, however, that the invention is not limited to the 
specific methods and instrumentalities disclosed. In the 
drawings : 

Figure 1 shows a partial block diagram of a system 
15 for multiplexing a plurality of digital services for 

transmission to a plurality of remote locations in accordance 
with the present invention; 

Figure 2 is a graphical illustration of the 
multiplex data stream generated by each encoder of Figure 1 
20 in accordance with the method of the present invention, and 
explains certain nomenclature used for understanding the 
system of the present invention; 

Figure 3 shows in detail the general arrangement 
and contents of a frame of the multiplex data stream of 
25 Figure 2 for transmitting NTSC video services in accordance 
with the present invention; 

Figure 4 shows in detail the data and services that 
can be carried in an exemplary first field of a frame of the 
multiplex data stream of Figure 2 in accordance with the 
3 0 method of the present invention ; 

Figure 5 shows in detail the data and services that 
can be carried in an exemplary second field of a frame of the 
multiplex data stream of Figure 2; 

Figure 6 illustrates the arrangement and content of 
3 5 the audio service portion of each field when twenty (20) 
audio services are carried in the multiplex data stream; 
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Figure 7 illustrates the arrangement and content of 
the audio service portion of each field when sixteen (16) 
audio services are carried in the multiplex data stream; 

Figure 8 shows in detail the general arrangement 
5 and contents of an exemplary video data packet; 

Figure 9 is a block diagram illustrating details of 
the service multiplexer of Figure 1 in accordance with the 
present invention ; 

Figure 10 graphically illustrates the reduction of 
10 burst errors during the transmission of a multiplex field in 
accordance with an aspect of the present invention; 

Figure 11 shows in detail the general arrangement 
and contents of the multiplex map transmitted in each field 
of the multiplex data stream in accordance with the method 
15 and system of the present invention; 

Figures 12 and 13 show in detail the general 
arrangement and contents of first and second video multiplex 
control packets that may be transmitted on consecutive lines 
of each field of the multiplex data stream; 
20 Figure 14 is a block diagram of another part of the 

system of the present invention showing one embodiment of a 
cable head-end installation; 

Figure 15 is a block diagram of a set -top decoder 
for receiving a multiplex data stream and extracting selected 
25 services therefrom in accordance with the present inventions- 
Figure 16 is a block diagram showing details of the 
service demultiplexers of Figure 15; 

Figure 17 is a block diagram of an alternate design 
of a cable head-end installation that may be employed in 
3 0 accordance with the system of the present inventions- 
Figure 18 shows in detail the general arrangement 
and contents of an addressable data packet that can be 
transmitted in a field of the multiplex data streams- 
Figure 19 shows in detail the general arrangement 
3 5. and contents of an exemplary first service seed packet that 
can be transmitted in a field of the multiplex data stream; 
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Figure 2 0 shows in detail the general arrangement 
and contents of an exemplary service seed packet that may be 
transmitted subsequent to the service seed packet shown in 
Figure 19; 

5 Figure 21 shows in detail the general arrangement 

and contents of a virtual channel map packet that can be 
transmitted in a field of the multiplex data stream; 

Figure 22 shows in detail the general arrangement 
and contents of an optional system packet that can be 
10 transmitted in a line of the multiplex data stream; 

Figure 23 illustrates the contents of the first 
thirteen lines of eight consecutive fields (i.e., one nominal 
" crypto- cycle " ) transmitted in accordance with the present 
invention; 

15 Figure 24 shows in detail the general arrangement 

and contents of a frame of the multiplex data stream of 
Figure 2 for transmitting PAL video services in accordance 
with the present invention; 

Figure 25 shows in detail the data and services 

20 that can be carried in an exemplary first field of the frame 
of Figure 24 ; 

Figure 2 6 shows in detail the data and services 
that can be carried in an exemplary second field of the frame 
of Figure 24; and 

25 Figure 27 shows in detail the general arrangement 

and contents of a frame of the multiplex data stream of 
Figure 2 for transmitting an HDTV video service in accordance 
with the present invention. 

Detailed Description of the Drawings 

3 0 In the drawings, like numerals indicate like 

elements throughout. As with the Background of the 
Invention, the following detailed description is presented in 
the context of subscription television systems, such as cable 
television and direct broadcast satellite (DBS) systems, that 

3 5 distribute a variety of program services to subscribers, but 
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the invention is by no means limited thereto except as 
expressly set forth in the accompanying claims . 

Figure 1 shows a partial block diagram of a system 
10 for multiplexing a plurality of digital services for 
5 transmission to a plurality of remote locations (not shown) . 
In the subscription television context, the system 10 
comprises a plurality of service encoders 12 each of which is 
operated by a "programmer." As illustrated, any number N of 
programmers may be present in the system 10. As mentioned in 
10 the background, programmers are entities that provide 

"programs" for distribution to various subscribers. For 
example, as shown in Figure 1, programmer 1 may provide 
programsl. .N. Each program comprises a set of related 
services, such as video, audio and closed-captioning 
15 services. By way of example, Figure 1 shows that programmerl 
is providing programl which comprises a video service 14 and 
two related audio services 16, 18. A given program can 
comprise a collection of related services, and a programmer 
may provide any number of programs . 
20 Typically, the individual services of each program 

are produced in an analog format . According to the system 
and method of the present invention, each encoder 12 has a 
plurality of analog- to- digital converters 20 for converting 
services in analog form to digital .services. In addition, 
25 video and audio services may be compressed by video and audio 
compression devices 22, however, compression is not required. 
As those skilled in the art know, there are many video and 
audio compression techniques available. For example, the 
Motion Pictures Expert Group (MPEG) has developed a video 
30 compression algorithm that is widely used in the digital 
video services industry. Vector quantization is another, 
more recent compression technique for digital video. 
According to the present invention, any compression algorithm 
may be employed by the video and audio compression devices 
35 22, and the devices 22 are by no means limited to any one 
compression method. Furthermore, as mentioned above, 
compression of audio and video services is not required. 
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Compression merely serves to increase the amount of data that 
can be transmitted within a given bandwidth. 

Each encoder further comprises a service 
multiplexer 24. As described hereinafter in greater detail, 
5 the service multiplexers 24 function in accordance with the 
method of the present invention to multiplex the individual 
digital services for transmission to remote locations (not 
shown) , such as a cable head-end installation or DBS 
subscriber. The service multiplexer 24 in each encoder 12 

10 generates a multiplex data stream which is fed to a 

transmitter 28 for transmission to the remote locations via a 
satellite 30. As illustrated in Figure 1, each programmer 
(e.g., programmerl . .programmerN) provides its own multiplex 
data stream 26. As described hereinafter in greater detail, 

15 the multiplex data streams may be received at various remote 
locations, such as a cable head-end, a DBS subscriber or a 
cable subscriber. Each remote location employs a service 
demultiplexer which extracts selected services from the 
multiplex stream in accordance with the method of the present 

2 0 invention. Further details of the service demultiplexer will 

be provided hereinafter. 

Figure 2 is a graphical illustration of the 
multiplex data stream 26 generated by each service 
multiplexer 24 in each encoder 12 . According to the present 
25 invention, the multiplex data stream 26 comprises a 

continuous sequence of "frames." Each frame consists of two 
"fields" as shown. As described hereinafter in greater 
detail, each field contains multiplexed service data and a 
"transport layer" that contains certain "system data" 

3 0 necessary for operating the system of the present invention. 

Because certain types of system data are too numerous to 
transmit in a single field, these types of data are 
transmitted over a series of fields referred to herein as a 
"cryptocycle . " According to the present embodiment, a 
35 cryptocycle nominally comprises eight (8) fields; however, a 
cryptocycle can be defined by any number of fields. 
Essentially, cryptocycles define fixed boundaries in the 
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multiplex data stream 26 within which a complete set of 
system and encryption related data is transmitted. As 
described hereinafter, the service demultiplexer at each 
remote location needs all the system data in a given 
5 cryptocycle in order to extract selected services from the 
service data contained in the next cryptocycle . 

As explained above in connection with Figure 1, the 
video services carried in a multiplex data stream typically 
originate as analog video signals (except for HDTV signals) , 
10 and as shown in Figure 1, the analog video signals are 
"digitized" by analog- to-digital converters 2 0 and thus 
u become "digital services." As described hereinafter in 
greater detail, at subscriber locations, selected digital 
video services are extracted from the multiplex data stream 
15 for viewing on a display device, such as a television, for 
example. Prior to viewing, however, the digital video 
services must be converted back to their analog form. As 
those skilled in the art know, there are several analog video 
signal fox-mats widely used in the television industries. The 
20 NTSC format is widely used in the United States, whereas the 
PAL format is used in most of Europe. In order to simplify 
hardware design and frequency generation throughout the 
system 10, the overall frame structure and transmission rate 
of the multiplex data stream 26 are related to, and depend 
25 upon, the particular analog video format of this video 

services being carried in the multiplex. The frame structure 
and digital transmission rate of the multiplex differ 
depending upon whether the video services carried in the 
multiplex are PAL video signals or NTSC video signals. 
3 0 Providing digital multiplex data rates and clocks that are 
related to key analog video frequencies simplifies hardware 
design throughout the system. In particular, the 
regeneration of analog video (as well as audio) signals at 
. subscriber locations is greatly simplified. 
3 5 Figure 3 shows the general arrangement and contents 

of a frame of the multiplex data stream of Figure 2 when the 
video services carried in the multiplex are based on the NTSC 
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video signal f ormat . The frame structure and transmission 
rate of the multiplex data stream are related to their analog 
NTSC counterparts. As described below in greater detail, for 
example, the overall data rate of the multiplex data stream 
5 is related to the analog television line frequency F h/ which 
in the case of NTSC video signals is 15.734 kHz (i.e., 
F h =15.734 kHz) . As illustrated in Figure 3, a frame 
comprises a plurality of lines each of which are 171 bytes 
long (i.e., 1368 bits). In the present embodiment , wherein 

10 the video services carried are NTSC format signals, the frame 
has 525 lines. As those skilled in the art will recognize, 
the 525 lines of the frame correspond to the number of lines 
in an analog NTSC picture. Additionally, each frame consists 
of two "fields," each of which contains 262 lines. A test 

15 line 4 0 is added to the second field to achieve the 525 line 
total . As those skilled in the art will further recognize , 
this two-field structure is analogous to the two-field format 
of NTSC signals. 

To achieve correspondence between the multiplex 

2 0 data rate and analog NTSC frequencies, each line of the frame 

is transmitted at a frequency equal to F h , the horizontal 

line frequency. In the case of NTSC video, F h is 15.734 kHz. 

Thus, when NTSC video services are carried in the multiplex, 

the multiplex data rate is : 

25 171 bytes x 8 bits x F h = 1368 x F h 

line byte 

= 1368 x 15.734 kHz 
= 21.5 Mbps 

As expected, with 525 lines, the overall frame rate is 29.97 

3 0 Hz which is equal to the analog frame rate of NTSC video 

signals. As those skilled in the art will recognize, the 
multiplex rate of 13 68 F h does not exactly match the NTSC 
regeneration rate. The NTSC regeneration rate is actually 
1365 F h , and therefore, decoders at subscriber locations must 
35 perform a rate conversion in order to accurately regenerate 
the analog NTSC video signals. A single 21.5 Mbps multiplex 
data stream may be modulated and transmitted within a 6Mhz 



;DOCID: <WO 9410775A1 I > 



1 



WO 94/10775 PCT/US93/10491 

- 13 - 

cable channel, and two 21.5 Mbps multiplex data streams can 
be interleaved and transmitted over a single C-Band satellite 
transponder . 

Referring still to Figure 3, each field of the 
5 frame begins with a VSYNC word 42, and each line begins with 
an HSYNC byte 46 followed by an offset byte. As described 
hereinafter, a service demultiplexer in a decoder at each 
subscriber location uses the HSYNC and VSYNC patterns to 
establish frame and field synchronization after receiving a 
10 multiplex data stream. The VSYNC word 42 is generated 

similarly for each field, but is bit -inverted every other 
field. The HSYNC byte 46 is the same for each line. The 
VSYNC word 42 in each field is followed by a "transport 
layer" 44. In general, the transport layer 44 in each field 
15 contains "system data" needed for operation of the system of 
the present invention, and more importantly, specifies the 
contents and structure of the "system data" and service data 
that follow in the field. As described hereinafter in 
greater detail, an important part of the transport layer 44 
20 is the "multiplex map" (not shown) which follows directly 
after the VSYNC word 42 in each field. In accordance with 
the present invention, the multiplex map specifies the number 
and location of transport layer packets that follow in the 
field and is dynamically adjustable on a per field basis to 
25 achieve great flexibility. 

As shown in Figure 3, the transport layer 44 of 
each field is followed by a service data space 48 which 
contains the audio and video service data carried in the 
multiplex data stream. As explained hereinafter in greater 
3 0 detail, the plurality of video services and audio services 
carried in each field are variably partitioned within the 
field so that the system can accommodate multiple service 
data rates . The data rate for a service can vary from the 
HDTV rate (approx. 17 Mbps) to the telecommunications 
3 5 standard Tl data rate of 1.544 Mbps. In accordance with the 
present invention, the amount of data assigned to video, 
audio and other services can be adjusted among the services. 
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portions of the service data space not used for audio 
services may be reassigned as video or other service data. 
Audio services are not tied to video services within the 
field, and therefore, the system can provide "radio" 
5 services. Because of the dynamic allocation of service data 
within a field, the individual video services are not 
required to have the same data rate . The possible 
combinations of services that a programmer can provide in one 
multiplex data stream are limited only by the maximum data 
10 rate of the multiplex data stream (i.e., 21.5 Mbps) and the 
variable partitioning increment size. With the flexible 
method of the present invention, any future digital services 
with data rates as low as the telecommunications standard Tl 
rate can be accommodated. As further shown, the transport 
15 layer 44 and service data portion 48 of each frame are error 
coded using a 20 byte Reed-Solomon error correcting code. 
Those skilled in the art will appreciate, however, that any 
block-oriented error correcting scheme may be employed 
without deviating from the true spirit and scope of the 
20 present invention. 

Figure 4 shows further details of the general 
arrangement and contents of the first field of an exemplary 
frame of a multiplex data stream in accordance with the 
present invention. As shown, the first line of the transport 
25 layer 44 (i.e., line 2 of the field) comprises a system data 
packet 60 (SDP) that includes a multiplex map 62. Subsequent 
lines of the transport layer may comprise service seed 
packets 64 (SSP) , video multiplex control packets 66 (VMCP) , 
virtual channel map packets 6 8 (VCM) , teletext data packets 
3 0 70 (TT) , addressable data packets 72 (ADP) , and optional 
system packets 74 (OSP) . In accordance with the method of 
the present invention, the multiplex map 62 is transmitted 
with each field and specifies the number and location of 
every other type of data packet in the transport layer 44 of 
35 that field. With the multiplex map 62, the number and 

location of each other type of transport layer packet may be 
dynamically altered on a per field basis to achieve a great 
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degree of flexibility. For example, as described below in 
greater detail, the multiplex map 62 can be used in a "full- 
field" mode to allow an entire field of the multiplex data 
stream to be used for system data such as addressable data 
5 packets 74 (ADPs) . It should be noted that not every type of 
transport layer packet need be transmitted in every field. 
For example, some packets, such as system seed packets 64 
(SSPs) , may be transmitted only in the first few fields of a 
cryptocycle. The content and arrangement of data within each 
10 packet will be described hereinafter in greater detail. 
Still referring to Figure 4, a portion of each 
field is allocated to service data 48. According to the 
method of the present invention, audio services, utility data 
and closed- captioning services and video services are 
15 separated within the field. As shown, utility and closed- 
captioning data may be transmitted at the beginning of each 
line of the transport layer 44 as well. The audio portion 78 
of each field is proportionally allocated among the various 
audio services being transmitted. The size of the audio 
20 portion 78 of each field is adjustable for accommodating 
different numbers of audio services. According to a 
preferred embodiment, the audio portion 78 of each field 
consists of a maximum of 21 bytes on each line of the service 
data area 48. 

25 The video portion 80 of the service data area 48 of 

each frame comprises a plurality of smaller video data 
packets 82 (VDPs) . In the present embodiment, the VDPs are 
each 60 bits wide, although any size VDP may be used without 
deviating from the spirit and scope of the invention. Each 

3 0 of the 60 bits in an VDP may be allocated to a particular 

video service being transmitted. For example, if there are 5 
video services being transmitted, each service could be 
allocated 12 bits out of every VDP. According to the method 
of the present invention, the 6 0 bits in each VDP are 

3 5 allocated among the various services in proportion to the 
individual data rate of each service. For example, a. video 
service having a high rate may be allocated more bits in each 
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VDP than a video service having a lower rate. Although the 
allocation of VDP bits in a single frame remains fixed, the 
allocation may be adjusted on a per frame basis. As 
explained hereafter in greater detail, the video multiplex 
5 control packets (VMCPs) 66 in the transport layer 44 specify 
the video service allocation within the VDPs of a given 
field. In the preferred embodiment, even though the VMCPs 
are transmitted in the transport layer of every field, the 
allocation of services within each VDP may be dynamically 

10 altered on a per frame basis only. In this manner, the 
system and method of the present invention supports 
statistical multiplexing. Those skilled in the art will 
appreciate, however, that the allocation of services within 
each VDP may be dynamically altered on a per field basis, if 

15 desired. 

Figure 5 shows details of a second field of an 
exemplary frame of a multiplex data stream. As can be seen, 
the second field is generally similar in structure and 
arrangement to the first field; the main difference being the 

20 addition of the test line 40. As mentioned previously, the 
test line 4 0 is the last line of every frame of the multiplex 
data stream and allows each field to be exactly 261 lines 
(not including VSYNC) . The test line 4 0 is not error coded 
with the Reed- Solomon code as are lines 2 64-524 of the second 

25 field. The test line may be used to carry system test data, 
if desired. 

Referring to both Figures 4 and 5, the third and 
fourth bytes on each line of each field carry utility and 
closed- captioning data. Only the first 15 of 16 bits are 

30 utilized for utility data; the 16th bit is used for closed- 
captioning data. Additionally, five lines in each frame 
(i.e., both fields) do not carry utility and closed- 
captioning data. These include the two VSYNC lines 42, the 
test line 40 and lines 2 and 264 of the first and second 

35 fields respectively. The total bit capacity for utility data 
for one frame is then: 

(525-5)lines * (15 bits/line) = 7800 bits. 
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In accordance with the present embodiment, those 7800 bits 

are partitioned into 8 separate "channels" of utility data. 

Thus, there are 975 bits/channel in each frame. These are 

error coded using a (3,2,13) convolution FEC to yield an 

5 error- corrected capacity of: 

975 * 2/3 = 650 bit s /channel /frame . 

The resultant maximum data rate for each channel of utility 

data is then: 

650 bits x 1 Frame x 15,743 lines = 19.4 8 KBps 
10 frame 525 lines s 

This rate is slightly higher than the industry standard 19.2 
KBps rate, but with the excess capacity, worst -case incoming 
data channels can be handled by running at the slightly 
higher rate. A 19.48 kHz clock is easily derived from F h 

15 since 19.48 kHz is equal to 2730/2205 F h . This illustrates 
one advantage of relating the overall multiplex data rate to 
the horizontal line frequency. Alternatively, the utility 
data in each frame can be partitioned into 16 separate 
channels, where each channel runs at 9600 Kbps . 

20 Closed-captioning data is transmitted in the last 

bit of the fourth byte of each line (i.e., bit 16 of the 
utility & closed-captioning data space) . As with the utility 
data, closed-captioning data (i.e., 1 bit per line) is sent 
on the same 520 lines of each frame. As those skilled in the 

25 art know, video services often have associated closed- 
captioning data. In the analog NTSC format, two bytes (i.e., 
two characters) of closed-captioning data are sent on line 21 
of each analog video frame . In accordance with the method of 
the present invention, the 520 closed-captioning bits are 

30 partitioned into 20 separate "channels" of 26 bits each. 

Each "channel" corresponds to a different video service in 
the multiplex data stream. In each frame, therefore, up to 
20 video services may carry associated closed captioning 
data. The first 26 bits in the frame correspond to video 

35 number 1, the second 26 bits correspond to video number 2, 

and so on. In the present embodiment, only the first sixteen 
bits of each 26 bit partition are used. Thus, as with line 
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21 in the analog NTSC format, two characters are transmitted 
per frame per video service . 

As mentioned above, the audio service portion 78 of 
each field is adjustable depending on the number of audio 
5 services being transmitted. Audio service data is only 
transmitted on 500 of the 520 lines of each frame. The 
amount of each line allocated to audio service data depends 
on the number of audio services being transmitted. Audio 
services are carried in groups of four "channels" where a 
10 channel is defined as a data rate of 8 F h . A rate of 8 F h was 
chosen because it corresponds approximately to 125.8 Kbps, 
which is near the single channel audio data rates for several 
standards in use throughout the audio and subscription 
television industries. Up to a maximum of 20 audio channels 
15 may be transmitted per frame according to the present 

embodiment. To satisfy the 8 F h data rate, each channel must 
be allocated 8 bits per line for every line in a frame. 
Because audio service data only appears on 50 0 of the 525 
lines, however, an additional byte must be sent every 20 
20 lines for each audio channel. Figure 6 illustrates the 

content and arrangement of the audio data portion of a field 
of the multiplex data stream when 20 channels of audio are 
carried. Figure 7 illustrates the content and arrangement 
when 16 channels of audio are carried. As explained 
25 hereinafter, the multiplex map 62 in each field specifies the 
number of audio channels carried in that field in order to 
provide the service multiplexers and service demultiplexers 
with the necessary information for inserting and extracting 
the audio services to and from the multiplex data stream, 
3 0 respectively. 

As mentioned above, video services are carried in 
the video service portion 80 of each field. The video 
service portion 8 0 comprises a plurality of video data 
packets 82 (VDPs) , each 60 bits wide. Portions of each VDP 
3 5 are allocated among the video services carried in the 

multiplex. Figure 8 illustrates an exemplary line N of a 
field of the multiplex data stream showing several VDPs 82. 
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In accordance with the method of the present invention, the 
VDPs 82 are spaced consecutively after the HSYNC, offset and 
audio service data on the line. Figure 8 also shows the 
contents of an exemplary VDP 82. In the example shown, four 
5 video services, 1, 2, 3 and 4, are being carried in the 
multiplex- Video services 1 and 2 have higher individual 
data rates than video services 3 and 4, and consequently, 
videos services 1 and 2 are each allocated 20 bits of the 
VDP r while video services 3 and 4 are eiach allocated only 10 

10 bits. As mentioned, the allocation of bits within each VDP 
is adjustable on a per frame basis. Although in the present 
embodiment the VDPs are sixty (60) bits wide, the VDPs may be 
any width, such as 8 0 bits wide or 120 bits wide, without 
deviating from the spirit and scope of the present invention. 

15 As described above, each programmer's multiplex 

data stream 26 is generated by the service multiplexer 24 in 
the programmer's encoder 12 (see Figure 1). Figure 9 is a 
block diagram of a service multiplexer 24 according to the 
present invention. The service multiplexer 24 operates in 

20 accordance with the method of the present invention, to 

multiplex a plurality of digital services for transmission to 
remote locations (not shown) . As shown in the Figure, a 
plurality of compressed digital video services V' x . -V' N , 
compressed digital audio services A' X ..A' V , and associated 

25 closed-caption data CC are input to the service multiplexer 
24. By way of example, these digital services may be the 
services input to the service multiplexer 24 of programmerl 
in Figure 1. As explained previously, the video and audio 
services need not be compressed, but for most applications 

3 0 compression is desirable. 

The service multiplexer 24 comprises a control 
computer 100 that controls the overall operation of the 
multiplexer 24 . Various parameters are input to the control 
computer 100 by the programmer, such as how many and what 

3 5 types of digital services are being multiplexed. In response 
to this information, the control computer 100 generates a 
multiplex map which, as described above, specifies the number 
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and location of various packets in the transport layer of the 
multiplex. Details of the content of the multiplex map will 
be provided hereinafter. The control computer 100 feeds the 
multiplex map to a storage memory 104. As described 
5 hereinafter, a field builder 150 "reads" the multiplex map in 
order to construct a field of the multiplex data stream. The 
control computer 100 generates a multiplex map for each 
field. As mentioned, the multiplex map is carried in a 
system data packet (SDP) that occupies the first line of 
10 every field after the VSYNC word. Accordingly, the control 
computer 100 also feeds the multiplex map to an SDP/SSP 
builder 106 which forms the SDP that contains the multiplex 
map . 

Figure 11 illustrates the general arrangement and 

15 contents of an exemplary system data packet (SDP) 200 that 
carries the multiplex map. As can be seen, the SDP 2 00 is 
preferably 156 bits long and comprises the multiplex map 2 02 
and a system data area 204 for carrying other system related 
information, such as system tuning information, global seeds 

20 or video parameter information. The system data area 2 04 may 
be used for any such system related information and the 
contents and arrangement of information within the system 
data area 204 are flexible. According to the present 
embodiment, the multiplex map 202 is 76 bits in length. The 

25 multiplex map (hereinafter sometimes referred to as the "mux 
map") 202 must be present in every field because it contains 
information regarding the contents and format of the rest of 
the field. Specifically, the mux map 202 describes the 
layout and type of packets and data in the transport layer of 

3 0 each field. As described hereinafter in greater detail, 

service demultiplexers at each remote location interpret the 
mux map 2 02 to determine how to extract the plurality of 
digital services from the multiplex data stream. As those 
skilled in the art will appreciate, the mux map 202 is 

35 critical to the functioning of the system of the present 
invention. Accordingly, the mux map is transmitted 
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unencrypted, and the SDP 200 within which the mux map 202 is 
located is heavily error corrected. 

As shown in Figure 11, the mux map includes an SDP 
header 206 that indicates that the SDP 200 contains the mux 
5 map 202. A crypto-cycle count 208 indicates which position 
in the cryptocycle that the particular field occupies. The 
crypto-cycle count 208 is necessary so that the decoders at 
remote locations know where the crypto-cycle boundaries 
occur. As described hereinafter, seeds used for encrypting 

10 each service are changed at every cryptocycle boundary. An 
SDP count 210 specifies the number of additional SDPs present 
in the field. Only the SDP 200 on the second line of every 
field carries the mux map 202. Other SDPs may be transmitted 
within a field, however, so that other system related 

15 information may be provided to the decoders at remote 

locations. According to the present embodiment, a maximum of 
32 SDPs are possible per field. A system seed packet count 
212 specifies the number of packets in the transport layer 
that contain encryption seeds. An ADP count 214 specifies 

2 0 the number of addressable data packets in the field. In a 

full-field mode, the ADP count may specify that the entire 
field of the multiplex contains ADPs . Thus, ADPs may be 
extended throughout the entire field. In addition, ADPs may 
be transmitted in place of teletext packets . A teletext 

25 count 216 specifies the number of teletext packets in the 
field. As with ADPs, the teletext packets can be extended 
throughout the entire field in the "full-field" mode. An OSP 
count 218 specifies the number of optional system packets in 
the field. Again, OSPs may be extended throughout the field 

30 in "full-field" mode. An audio count 220 specifies the 
number of audio services carried in the multiplex data 
stream. As described above in connection with Figures 6 and 
7, audio services are carried in groups of "four channels." 
Thus, the audio count may specify either 0, 4, 8, 12, 16 or 

3 5 2 0 audio services. As explained hereinafter, the audio count 

22 0 determines the how the audio data space in each field is 
allocated among the audio services. A virtual channel map 
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(VCM) count 222 specifies the number of virtual channel map 
packets that are carried in a given field. Virtual channel 
maps are described hereinafter. A video multiplex control 
packet count 224 indicates the number of video multiplex 
5 control packets that are carried in the field. As described 
hereinafter, the video multiplex control packets specify the 
number of bits in each video data packet (VDP) that are 
allocated to each video service. An HD select bit 226 is 
provided for indicating whether the field carries High 

10 Definition Television (HDTV) information. The format of a 
field in HD mode will be described later. The mux map 202 
ends with seventeen (17) spare bits which may be used for 
future expansion of the system. The general contents and 
arrangement of each of the other packets carried in the 

15 transport layer will be described hereinafter. 

Referring again to Figure 9, each of the digital 
video services, V'^.V'h, and digital audio services, 
A'i-.A'n, are fed to individual service encryptors 108. 
Digital service encryptors are well known to those skilled in 

2 0 the art, and there are many encryption techniques and many 

ways to implement an encryptor , In the present invention, 
the encryptors 108 are not limited to any one technique or 
implementation. However, an important feature of the present 
invention is that each digital service is independently 
25 encrypted. 

Data encryptors, such as encryptors 108, typically 
use a "seed" value to generate a pseudo-random binary 
sequence which is then convolved, typically via modulo- 2 
addition, with the service data stream to produce an 

3 0 encrypted service stream. Accordingly, the multiplexer 24 

includes a service seed generator 109 for supplying each 
encryptor 108 with its own "seed" value. Thus, each service 
within the multiplex data stream is individually encrypted 
using a unique service seed. As those skilled in the art 
3 5 know, a service can be decrypted as long as the decryptor has 
the "seed" used to encrypt the service. According to the 
present invention, the seed used to encrypt a given service 



IDOCID: <WO 9410775A1J_> 



WO 94/10775 



PCT/US93/10491 



- 23 - 

is changed periodically. More specif ically, the service 
seeds are changed every cryptocycle,. which in the preferred 
embodiment, comprise eight (8) fields. Thus, a given seed 
value is used to encrypt a particular service over 8 fields 
5 of the multiplex data stream and then changed. Changing the 
service seeds every cryptocycle enhances the cryptographic 
strength of the system. As described hereinafter, the 
service seeds are transmitted to the remote locations in 
service seed packets (SSPs) . As shown in Figure 9, 
10 therefore, the service seed generator 109 provides the seeds 
to the SDP/SSP builder 106 which constructs the service seed 
packets (SSPs) . Details of the contents and arrangement of 
an SSP are provided hereinafter. 

As those skilled in the art will appreciate, time 
15 is needed at a remote location to receive the seeds and 
process them in order to be ready to decrypt the incoming 
encrypted service data. Accordingly, seeds are transmitted 
to remote locations one cryptocycle in advance of the data 
the seeds were used to encrypt . This allows the 
20 demultiplexer in the decoder at each remote location enough 
time to have the seeds ready for the decryption process and 
avoids unnecessary buffering of the incoming service data 
stream. 

The encrypted video services are fed to a video 
25 service multiplexer 114 that constructs the video data 

packets VDPs . The control computer 100 feeds video multiplex 
control packets (VMCPS) to the video multiplexer 114 via line 
116. The video service multiplexer allocates portions of 
each VDP to each video service in accordance with the 
30 information contained in the VMCPs. The VMCPs are also fed 
to a forward error correction (FEC) circuit 13 0 where error 
code bits are added to the VMCP. From the FEC circuit 13 0, 
the VMCPs are fed to the field builder 150 where they are 
inserted into each field of the multiplex data stream. As 
35 explained, the multiplex map specifies where in each field 
the VMCPs are located. According to the method of the 
present invention, when the multiplex data stream 26 is 
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received at a remote location, a service demultiplexer in a 
decoder at that location extracts the multiplex map from each 
field, determines the location of the VMCPs in the field, and 
employs the VMCP information to determine the video service 
5 allocation in each VDP. In this manner, the video services 
can be extracted from the multiplex data stream. 

According to the present embodiment, up to two 
VMCPs may be transmitted with every field of the multiplex 
data stream. Each VMCP specifies the allocation or "video 

10 weighting" for up to 10 video services. Thus, if no more 
than 10 services are carried in the multiplex data stream, 
then only one VMCP is needed per field. If more than 10 
video services are carried, however, an additional VMCP is 
needed. In the present embodiment, no more than 2 0 video 

15 services may be carried in the multiplex, and therefore, no 
more than two VMCPs are ever transmitted in a given field. 
Those skilled in the art will appreciate, however, that the 
system of the present invention does not have to be limited 
to 2 0 video services, and therefore, any number of video 

2 0 services and requisite VMCPs may be transmitted per field. 
For example, up to forty video services could be carried in 
which case as many as four VMCPs may be transmitted per 
field. 

Figure 12 shows the general arrangement and 
25 contents of a VMCP 230 that specifies the video weighting 

(i.e., allocation) for the first 10 video services carried in 
the multiplex of the present example. As can be seen, the 
VMCP contains a first data field 232 that specifies the video 
weighting. Each video service (i.e., services 1-10) is 
30 represented by a 6 -bit descriptor that indicates how many 
bits of each video data packet (VDP) are allocated to that 
service. The first six bits of the video weighting field 232 
of the VMCP 230 contain the descriptor for video 1, the 
second six bits contain the descriptor for video 2, and so 
35 on. An additional data field 234 is provided in the VMCP for 
carrying other information about the video services, such as, 
for example, panscan control information and/or EIDAK control 
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information. Figure 13 illustrates the contents of a second 
VMCP 23 6 required if more than 10 video services are to be 
carried in the multiplex data stream. The format of the 
second VMCP 23 6 is identical to that of the first VMCP 23 0 of 
5 Figure 12, except that the video weighting field 238 and 
additional data field 24 0 provide video weighting and other 
information for services 11 through 20. As explained, the 
VMCPs are employed in the service multiplexers and 
demultiplexers to facilitate insertion and extraction of 
10 individual video services from each field of the multiplex 
data stream. 

The digital audio services, e.g. A'^.A',,, are fed 
to an audio service multiplexer 110. The control computer 
100, via line 112, provides the audio multiplexer 110 with an 
15 indication of how many audio services are to be multiplexed. 
As described previously in connection with Figures 6 and 7, 
audio services are carried in groups of four "channels", and 
up to 20 audio channels may be transmitted per field 
according to the present embodiment. Figures 6 shows how the 

20 audio service multiplexer 110 multiplexes twenty audio 

services for insertion in a given field of the multiplex data 
stream. Figure 7 shows how sixteen audio services are 
multiplexed by the audio multiplexer 110. 

A utility data and closed- caption data multiplexer 

25 118 accepts utility data from the control computer via line 
124 and closed caption data via line 125. The multiplexer 
118 constructs the two bytes of utility data and closed- 
captioning data that appear on 520 lines of each field of the 
multiplex data stream. The content and arrangement of the 

30 utility and closed-captioning data is described above in 
connection with Figure 4 . 

The video data packets (VDPs) , multiplexed audio 
services, and utility and closed-caption data are fed to the 
, field builder 150 via lines 120, 122, and 126 respectively. 

35 As mentioned, the field builder 150 constructs each field of 
the multiplex data stream according to the information 
contained in the multiplex map. According to one embodiment 



WO 94/10775 



PCT/US93/10491 



- 26 - 

of the present invention, the VDPs, multiplexed audio 
services and utility and closed-captioning data may be 
further encrypted with a global encrypter 128. The global 
encryptor 128 may be functionally equivalent to the 
5 independent service encryptors 108. A global seed generator 
13 0 creates the seed value used by the global encryptor 128 
to encrypt the VDPs, multiplexed audio services and utility 
and closed-caption data. As with the independent service 
seeds, the global seed is changed every cryptocycle. The 

10 global seeds must also be transmitted to each remote location 
so that the "global layer" of encryption may be removed. To 
this end, the global seed generator 130 also provides the 
global seeds to the SDP/SSP builder 106 which inserts the 
global seeds in a system data packet 106 that is carried in 

15 at least one field of every cryptocycle. 

The control computer 100 also generates a virtual 
channel map packet (VCMP) that is fed via line 132 to the 
field builder 150. Details of the contents and arrangement 
of a virtual channel map packet will be provided hereinafter. 

20 Basically, the virtual channel map provides a relationship 
between a television channel selected by a subscriber and a 
video service carried in the multiplex data stream. As 
described hereinafter in greater detail, when a subscriber 
selects a "television channel" for viewing, the service 

25 demultiplexer in a decoder at the subscriber location 

interprets the virtual channel map to determine which video 
service in the multiplex data stream corresponds to the 
selected television channel . Once the decoder knows which 
video service to extract, the demultiplexer interprets the 

3 0 video multiplex control packet (VMCP) to determine which bits 
in each video data packet (VDP) are allocated to that 
selected video service. With this information, the 
demultiplexer then can extract the selected video service 
from each VDP in the multiplex data stream. 

3 5 A programmer or a cable operator may wish to 

provide teletext data to the subscribers at various remote 
locations. Teletext data can be displayed on a subscriber's 
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television set to convey various information to the 
subscriber. To this end, the control computer 100 can feed 
teletext data to the field builder 150 for insertion into 
various fields of the multiplex data stream. 
5 As described hereinafter in greater detail, the 

control computer 100 may also provide subscriber specific 
information, known as "addressable data". This information 
is fed to an addressable data packet (ADP) builder 13 8 which 
constructs individual ADPs. An ADP contains a unique user 
10 address which acts as a "wake-up" call to a single target 
decoder in the system. ADPs carry subscriber specific 
information to individual subscribers. For example, an ADP 
may carry service authorization information which alerts a 
particular subscriber's decoder as to which services the 
15 subscriber has paid for. ADPs provide important information, 
and therefore, are error protected using a combination of FEC 
and CRC error codes as shown at block 142. 

As mentioned, the field builder 150 interprets or 
"reads" the multiplex map and constructs each field of the 
20 multiplex data stream according to the multiplex map for that 
field. A clock generator 152 provides a clock signal to the 
field builder to insure that the individual lines of each 
field are generated at the proper rate, which according to 
the preferred embodiment is equal to the horizontal 
25 television line rate, F h , of the particular video format 

being employed throughout the system (e.g. PAL or NTSC) . As 
those skilled in the art will appreciate, the relation to 
analog video frequencies simplifies hardware design in that 
standard analog video circuitry may easily be employed to 
3 0 produce analog compatible television signals at subscriber 
locations and all clock frequencies required in the system 
may be derived from a base frequency using suitable phase - 
lock loops and frequency dividers and multipliers. Once 
. constructed, successive lines of each field are fed to a 
35 Reed-Solomon error coding circuit 154* that adds additional 

parity bytes to each line according to the Reed- Solomon error 
coding technique. As those skilled in the art will 
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appreciate, other forms of block error coding may be used, 
and the present invention is by no means limited to the use 
of a Reed-Solomon code. For example, another non-binary BCH 
error coding technique may be employed, 
5 The fully constructed, error coded fields are next 

sent to a frame former 156 that inserts the HSYNC and offset 
bytes at the beginning of each line of every field and also 
inserts the VSYNC word at the beginning of each field. For 
every two fields, i.e., every frame, the frame former 156 

10 inserts the test line to ensure that each frame comprises the 
proper number of lines. As described above, the overall 
number of lines in each frame corresponds to the number of 
"lines" in the particular analog video format being employed 
throughout the system. For example, when NTSC video signals 

15 are being employed, each frame comprises 525 lines; when PAL 
video signals are being employed, each frame comprises 625 
lines . 

The output of the frame former 156 is a complete 
multiplex data stream, such as data stream 26 in Figure 1. 

2 0 The multiplex data stream output from the frame former 156 

may be transmitted directly to remote locations. According 
to a most preferred embodiment of the present invention, 
however, portions of the each frame of the multiplex data 
stream are transmitted in an interleaved format. As shown in 
25 Figure 9, therefore, the multiplex data stream is fed to an 
interleaver 162. At block 162, the data in each frame, 
excluding the VSYNC words, HSYNC and offset bytes, and test 
line, is transmitted in an interleaved manner. Essentially, 
therefore, all the data that is protected by the Reed-Solomon 

3 0 error code is transmitted in an interleaved fashion. By 

interleaving the data, burst error protection increases 
linearly by a factor equal to the number of lines of 
interleaved data. Figure 10 illustrates the advantages of 
interleaving. Without interleaving, a field 170 of the 
3 5 multiplex may encounter a burst error 172 that corrupts an 
entire line of the field 170. The Reed-Solomon error coding 
performed on each line is incapable of correcting such a 
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large number of corrupted bits. By transmitting the field in 
an interleaved manner and then de-interleaving at the 
receiver, that burst error 172 is spread over multiple lines 
of the field 170, as shown. Thus, only a single bit in each 
5 line is corrupted. As those skilled in the art know, the 
Reed- Solomon error code applied to each line is very capable 
of correcting a single bit error in a given line of the 
field. 

In accordance with the present invention, the 
10 multiplex data stream 26 is fed to a transmitter (not shown) 
for transmission to a plurality of remote locations in the 
system. A remote location may be a DBS subscriber, cable 
head-end installation or a cable subscriber. As those 
skilled in the art will appreciate, the multiplex data 
15 streams 26 generated by each programmer (see Figure 1) must 
be modulated prior to transmission via satellite. Typically, 
each programmer modulates its multiplex data stream on a 
unique frequency for transmission over a single satellite 
transponder operating at that frequency. At the remote 

2 0 locations, receivers are needed to receive the multiplex data 

streams and demodulate them. 

Figure 14 is a block diagram illustrating further 
details of the system 10 of the present invention. Whereas 
Figure 1 illustrated the details of various programmer 
25 locations, Figure 14 illustrates the details of various 

remote locations, including a DBS subscriber location 250, a 
cable head-end installation 252, and cable subscriber 
locations 254. By way of example, the multiplex data stream 
2 6 transmitted by programmerl in Figure 1 is indicated in 

3 0 Figure 14 as a solid line, and the multiplex data stream 26' 

transmitted by programmerN in Figure 1 is indicated by the 
dashed line. It is understood that there may be many 
programmers in the system of the present invention, and 
therefore, a plurality of multiplex data streams may be 
35 transmitted via satellite, to the remote locations. 

As shown in Figure 14, in the case of a DBS 
subscriber 250, the subscriber has a satellite down-link 256 
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for receiving a selected multiplex data stream from the 
satellite 30. A receiver 258 receives and demodulates the 
selected multiplex data stream. A set-top decoder 260 is 
provided at the DBS subscriber location 270 for extracting 
5 selected digital services from the multiplex data stream for 
display on a television set 270 at the location 250. Details 
of the set-top decoder 260 will be provided hereinafter. 

In the case of a cable head-end installation, e.g. 
installation 252 of Figure 14, multiple receivers 272 are 
10 provided for receiving multiple multiplex data streams from 
various programmers. Each multiplex data stream is received 
via a satellite down-link 262 and demodulated with a 
respective one of the receivers 272 . As those skilled in the 
art know, coaxial cables used in cable distribution networks 
15 have the capacity to carry a plurality of contiguous 6, 7 or 
8 MHz channels. In accordance with the preferred embodiment 
of the present invention, each multiplex data stream received 
at cable head-end 252 is fed from its respective receiver 272 
to a modulator 274, where it is modulated on a distinct 6 MHz 
20 cable channel. Although 6 MHz channels are employed in the 
preferred embodiment, 7 or 8 MHz channel may be employed. In 
the preferred embodiment, the modulators 274 employ 4-VSB 
(vestigial side-band) modulation, however, any suitable 
modulation technique may be employed. Each of the modulated 
25 data streams is then provided to a combiner 278 that combines 
the individual 6 Mhz channels into a single wide-band signal 
that is then transmitted via a cable distribution network 278 
to a plurality of cable subscriber locations 254. Each 
subscriber location 254 has a decoder 280 (similar to the 
3 0 decoder 260 of the DBS subscriber 250) that extracts selected 
digital services from a selected multiplex data stream for 
display on a television set 282 at the subscriber location 
254 . 

Figure 15 provides a detailed block diagram of the 
35 decoders 280 of Figure 14. As shown, the decoders 280 
comprise a demodulator 290 for demodulating incoming 
multiplex data streams. A tuner 292 provides the demodulator 
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290 with the appropriate carrier frequency signal for 
demodulating a selected multiplex data stream. Recall from 
Figure 14 that each multiplex data stream received at the 
cable head-end installation 252 is modulated on a unique 6 
5 Mhz channel. When a subscriber selects a television channel 
(i.e. video and related audio services), the selection is 
input to a tuning map 294 stored within the tuner 292. The 
tuning map 294 "maps" the subscribers selection with the 
multiplex data stream that carries the selected services. In 
10 response, the tuner 292 supplies the demodulator 290 with the 
appropriate carrier frequency for demodulating the particular 
multiplex data stream containing the selected services. 
Thus, in response to a subscriber's selection, the decoder 
280 "tunes" to the appropriate 6 MHz cable channel that 
15 contains the multiplex data stream within which the selected 
services are carried. Once the appropriate multiplex data 
stream has been received and demodulated it is fed to a 
service demultiplexer 298 that operates in accordance with 
the method of the present invention to extract the selected 
20 services from the multiplex data stream. Details of the 
demultiplexer 298 are provided hereinafter. 

As described previously, the digital video and 
audio services may be compressed at the encoder 12 of each 
programmer. Consequently, the decoders 280 at each 
25 subscriber location further comprise data decompressors 300 
for decompressing the compressed digital video and audio 
services extracted from the multiplex data stream by the 
demultiplexer 298. Video related services, such as video 
services, associated closed-captioning data, and teletext 
3 0 data are fed to a video processor 3 02 which converts the 

digital service information back into an appropriate analog 
video format, such as NTSC or PAL, for display on a 
television set 306 at the subscriber location. As described 
above, in accordance with the present invention, various 
3 5 parameters of the multiplex data stream, such as the number 
of lines in each field and the rate at which each line is 
transmitted, are related to the particular analog video 
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format being produced by the video processor 3 02 in each 
decoder. So far, the general arrangement and contents of the 
fields of the multiplex data stream have been described for 
the case where the video processor 3 02 is designed to 
5 reconstruct NTSC format signals . Details of the arrangement 
and contents of the multiplex fields in the case where PAL 
video is being employed are provided hereinafter. According 
to the invention, the video processor 302 of each decoder 280 
employs standard analog devices for genierating analog video 
10 signals. The particular devices employed again depend upon 
whether the system is being used to generate PAL video, NTSC 
video or some other format . 

According to the present embodiment, the 
demultiplexer is capable of extracting four audio services or 
15 "channels" at a time. As shown in Figure 15, each of the 
extracted audio signals is fed to a decompressor 3 00 for 
decompression. An audio processor 3 04 is provided for 
converting the digital audio services to analog format for 
output to a speaker device 308. As mentioned previously, 
20 there are many digital and analog formats in use throughout 
the industry, and the present invention is not limited to any 
one format. Accordingly, the function of the service 
multiplexers and demultiplexers in the system of the present 
invention is not dependent upon the particular audio formats 
25 being- used. The system may use the SEDAT-1 audio format, or 
some other format . 

The decoders 260 employed at DBS subscriber 
locations function similarly to the decoders 28 0 at cable 
subscriber locations. The difference is that, in a DBS 
3 0 decoder, the tuner 292 "tunes" to a particular satellite 

transponder rather than a particular 6 MHz cable channel in 
order to receive and demodulate the appropriate multiplex 
data stream carrying the services that the subscriber 
selected . 

35 Figure 16 is a functional block diagram of the 

service demultiplexer 298 of Figure 15.' The demultiplexer 
298 receives a multiplex data stream at an input 319. A de- 
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interleaver 320 de- interleaves the portions of the multiplex 
data stream that are transmitted in an interleaved format. 
Next, a synchronizer 322 establishes frame and field 
synchronization. In accordance with the method of the 
5 present invention, field synchronization is established using 
a two- level syncing strategy. First, the synchronizer 322 
searches for a repeating HSYNC pattern within the multiplex 
data stream. Although the HSYNC byte transmitted with every 
line of the field is a unique bit pattern, it is 
10 statistically likely to appear within other portions of the 
multiplex data stream. Its recurrence at precise line 
intervals, however, is very unlikely. Upon detecting a first 
HSYNC pattern, the synchronizer 322 looks to see if another 
HSYNC pattern exists exactly 169 bytes later (i.e., the next 
15 line of the field) . After detecting a pre -determined number 
of repeating HSYNC patterns at the appropriate line 
intervals, the synchronizer 322 assumes it has established 
line synchronization. Next, the synchronizer 322 searches 
for the VSYNC pattern in order to complete the field 
20 synchronization process. Finding a VSYNC word is much easier 
once the synchronizer 322 has established HSYNC, because a 
VSYNC pattern always immediately follows an HSYNC. Thus, the 
synchronizer 322 simply examines the bits that follow each 
HSYNC until it finds a VSYNC pattern. As mentioned above, 
25 the unique VSYNC pattern is much longer (169 bytes) than the 
HSYNC patterns. Statistically, the VSYNC pattern is very 
unlikely to occur randomly in a multiplex data stream. As 
those skilled in the art will appreciate, the two- level 
syncing approach used herein speeds field synchronization. 
30 Once field synchronization has been established, 

the multiplex data stream passes through error correction 
circuitry 324. As explained above, certain of the lines of 
each field are error coded. In the preferred embodiment, a 
Reed-Solomon code is employed. In particular, twenty (20) 
3 5 Reed- Solomon parity bytes are transmitted at the end of each 
of those lines. The error correction circuitry 324 examines 
the parity bytes to determine if any errors have occurred in 
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transmission and corrects the errors, if possible, in 
accordance with the Reed-Solomon error correction algorithm. 
If an uncorrectable error occurs, the error correction 
circuitry 324 provides an error signal to a control 
5 microprocessor 338. 

After detecting and correcting any bit errors, the 
multiplex map for each field of the multiplex data stream is 
extracted at block 326. Each of the fields of the multiplex 
data stream are processed one at a time in the sequence that 
10 they are received. When a field is received, the multiplex 
map is temporarily stored in a memory 328 for use by various 
other parts of the demultiplexer 298. 

Once the multiplex map has been extracted and 
stored, the multiplex data stream passes to a field 
15 deconstructor 330. The field deconstructor 330 "reads" the 
multiplex map for a given field to determine where the 
transport layer packets are located. The transport layer 
packets (e.g., SDPs, SSPs, ADPs, TT lines, VMCPs and VCMs) 
are passed to a transport layer demultiplexer 336 that again 
20 "reads" the multiplex map to extract the individual packets 
from the transport layer and provide each packet to various 
other parts of the demultiplexer 298. 

As shown in Figure 16, the transport layer 
demultiplexer 336 passes system data packets (SDPs) and 
25 system seed packets (SSPs) directly to a control 

microprocessor 338 via line 337* The control microprocessor 
338 extracts the service seeds and/or global seeds from the 
SSPs and SDPs, respectively. As explained above, the seeds 
used to encrypt service data during a given cryptocycle are 
3 0 actually carried in the SSPs and SDPs of the previous 

cryptocycle so that the demultiplexer 298 has sufficient time 
to prepare for decryption. 

The video data packets (VDPs) , multiplexed audio 
channels, and utility and closed-captioning data are provided 
35 by the field deconstructor 330 to a global decryption circuit 
340 via line 334. As explained above, the global layer of 
encryption is optional in the system of the present 
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invention, and therefore, the global decryption circuit 34 0 
may not be provided. In the case where global encryption is 
employed, however, the control microprocessor provides global 
seeds to the decryption circuit 340 for decrypting the 
5 globally encrypted service data. Once the global layer of 
encryption has been removed by the global decryption circuit 
340, the service data is passed to a service extractor 344 
where selected services are extracted from the multiplex data 
stream in accordance with the method of the present 
10 invention. 

Still . referring to Figure 16, addressable data 
packets (ADPs) are passed from the transport layer 
demultiplexer 336 to an address decoder 360. The decoders 
provided to each subscriber (e.g. decoder 280 of Figure 15) 
15 contain a unique public address that is stored in the decoder 
at the factory. Addressable data packets have an address 
field that contains a unique decoder address . The address 
decoder 360 in the service demultiplexer 298 examines the 
address field of every ADP to determine if a given ADP is 

2 0 "addressed" to that decoder. If so, the address decoder 360 

passes the ADP to the control microprocessor 338. which 
extracts the information from the ADP and responds 
accordingly. An addressable data packet may contain various 
subscriber specific information, such as, for example, 

25 service authorization information that informs the service 

demultiplexer 298 which services the subscriber has paid for. 
If a subscriber tunes to a "channel" that he has not paid 
for, the control micro-processor will be able to "block" 
access to that service; the control microprocessor may have 

30 security features built-in, or may pass information to a 

security element within the decoder. With ADPs, therefore, a 
cable operator is able to maintain individual control over 
the decoders installed throughout the system. Further 
details of the general arrangement and contents of an ADP 

3 5 will be provided hereinafter. 

According to the method of the present invention, 
the virtual channel map (VCM) is extracted from the transport 
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layer by the transport layer demultiplexer 33 6 and provided 
to a virtual channel map interpreter 348. A subscriber's 
service selection is also provided to the VCM interpreter 34 8 
via line 346. As explained above, the subscriber's selection 
5 is in the form of a "virtual channel." To the subscriber, a 
"virtual channel" is simply the channel number displayed on 
the set -top decoder attached to the subscriber's television 
or displayed using a graphical user interface or some other 
device at the subscriber location. The VCM interpreter 34 8 
10 receives the subscriber's "virtual channel" selection, and 
interprets the virtual channel map to determine which video, 
audio, teletext, closed-captioning and data services in the 
multiplex data stream are associated with that subscriber's 
virtual channel selection. A system operator can re-define 
15 the services associated with a given virtual channel by 
simply modifying the virtual channel map. Once the VCM 
interpreter 34 8 has determined which digital services in the 
multiplex data stream are associated with the subscriber's 
channel selection, it provides service ID'S for each of those 
20 services to the service extractor 344. For example, a 
subscriber may select "channel 12" on the subscriber's 
television. The virtual channel map may indicate that 
"channel 12" corresponds to video service 3, audio service 2, 
and the closed-captioning data associated with video service 
25 3. This information is transmitted to the service extractor 
344 via line 354. 

To facilitate extraction of the appropriate video 
service, the service extractor 354 receives the video 
multiplex control packets (VMCPs) for each field. As 
3 0 explained above, the VMCPs specify which bits in each video 
data packet (VDP) are allocated to each service. Thus, 
having received the service ID from the VCM interpreter 348 
and the VMCP, the service extractor 344 is able to extract 
the bits for that video service from each VDP in the current 
35 field. The service extractor 344 also knows how many audio 
services are being carried in the multiplex, and therefore, 
knows the format of the audio service data. Recall that 
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Figure 6 illustrates the format of the audio service data for 
the case of twenty video services, and Figure 7 illustrates 
the format for the case of 16 video services . Knowing this 
format, the service extractor 344 is able to extract the 
5 appropriate audio service . According to the preferred 
embodiment, the service extractor may extract up to four 
audio services per field. Closed- captioning data, if any, is 
extracted in a similar manner* 

At this stage, the extracted video and audio 
10 services are still independently encrypted. As shown in 
Figure 16, the video and audio services are passed to 
individual service decryptors 358 for decryption. The 
requisite encryption seeds are provided to the respective 
decryptors 358 via line 356. The extracted services are then 
15 output from the demultiplexer 298 via respective lines 359. 
In addition to video, audio and closed- captioning data, 
teletext data that has been retrieved from the teletext 
packets in the transport layer is output from the service 
demultiplexer 298 via line 362. 
20 Figure 17 is a block diagram of an alternate design 

of a cable head-end installation 400 for use in the system of 
the present invention. The alternate cable head-end 
installation 4 00 allows cable operators to generate their own 
multiplex data streams using the services originally provided 
25 by various programmers as well as their own local 

programming. The cable head-end installation 4 00 comprises a 
plurality of receivers 4 02 each for receiving a multiplex 
data stream from a particular programmer (e.g. programmers 1 
to N of Figure 1) . In the cable head-end installation 252 of 
30 Figure 14, the multiplexed data streams received from the 
programmers were left intact and passed directly to 
subscribers via cable. As shown in Figure 17, however, the 
alternate cable head-end installation 4 00 comprises a 
plurality of service demultiplexers 4 04 for extracting the 
3 5 individual services from each of the multiplexed data streams 
received at the installation 400. Each of the service 
demultiplexers 404 may be identical to the service 
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demultiplexer 298 shown in Figure 16. For each multiplex 
data stream received at the installation 4 00, a respective 
service demultiplexer 404 extracts the services carried in 
that multiplex data stream in accordance with the method 
5 described previously in connection with Figure 16 . Service 
multiplexers 406, which may be identical to the service 
multiplexers 24 of Figure 1, are provided for re-multiplexing 
the extracted services. As shown, therefore, a cable 
operator may mix services from different programmers, and may 

10 add their own local programs, as illustrated at block 408. 
Each of the multiplex data streams generated by the service 
multiplexers 4 06 is then modulated on its own 6 MHz cable 
channel using modulators 410. The individually modulated 
data streams are then passed to a combiner 412 that combines 

15 them into a single wide -band signal for transmission to cable 
subscribers via a cable distribution network. In these 
latter respects, the cable head-end installation 400 of 
Figure 17 functions identically to the cable head- end 
installation 252 of Figure 14. 

20 Figure 18 shows the general arrangement and 

contents of an exemplary addressable data packet 420 (ADP) . 
The small number in the lower left corner of each packet 
field indicates how many bits that field comprises. As 
shown, the first two bits of the ADP 420 are unused. A 

2 5 packet length field 424 contains the overall length of the 

packet in bits. Consequently, the packet length may be 
varied, as long as it does not exceed a single line in a 
given field of the multiplex data stream. A clear address 
field 426 contains the public address of the decoder to which 

3 0 the ADP is targeted. As explained above in connection with 

Figure 16, the decoders provided at every subscriber location 
contain a unique public address that identifies that decoder, 
and the service demultiplexer (e.g. demultiplexer 298 of 
Figure 16) in the decoder examines the clear address field 
3 5 426 of all incoming ADPs and accepts those ADPs that contain 
the address of that particular decoder. In this manner, 
therefore, subscriber specific information may be transmitted 
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to individual decoders. The address of a given decoder is 
set at the factory when the decoder is manufactured. A 
secret serial number (SSN) may also be stored in each 
decoder. The secret serial number can be used to encrypt the 
5 information carried in an ADP . A secret serial number select 
field 428 is provided for alerting the decoder as to whether 
the information in the ADP 42 0 is encrypted with the 
decoder's SSN. A command code field 430 holds a sixteen bit 
"command" that can be used to control a decoder. The upper 

10 six bits of the two byte code select a given "command set." 
The remaining ten bits specify the actual command. A data 
field 432 provides accompanying data for the command in the 
command field 430. This arrangement allows for 64 
independent command sets with 1024 commands in each set. For 

15 example, a "command" may be transmitted in the command field 
43 0 that tells the target decoder to store the information in 
the data field 43 2 in a memory at the decoder. A twenty- four 
bit CRC 434 follows at the end of the ADP 42 0 to ensure the 
accuracy of the information contained within the ADP 420. If 

20 a decoder detects an error in a given ADP, it discards the 
entire ADP. 

Figure 19 shows the general arrangement and 
contents of a first service seed packet (SSP) 44 0 that must 
be transmitted in a given cryptocycle of a multiplex data 

25 stream. As briefly described above, the individual service 
seeds used to encrypt the services during each cryptocycle 
are transmitted to subscriber locations so that the decoders 
at these locations can decrypt the extracted service data 
streams. Furthermore, the seeds used to encrypt service data 

30 in the fields of a given cryptocycle are transmitted one 

cryptocycle in advance of the encrypted service data so that 
the decoders have enough time to extract the seeds and 
prepare for decryption. In the preferred embodiment 
described herein, only video and audio services are 

35 encrypted. However, other services, such as utility data and 
teletext data may also be encrypted. Consequently, the 
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exemplary system seed packet 440 (SSP) of Figure 19 may be 
modified to provide for those cases. 

As mentioned, Figure 19 illustrates the arrangement 
and contents of a first SSP that must be transmitted during a 
5 given cryptocycle. Since the number of services carried in a 
multiplex data stream can vary, it is necessary to provide 
flexibility in the transmission of the service seeds. To 
this end, the first SSP 440 in a given cryptocycle contains a 
first header 442, identifying the packet as a service seed 

10 packet, and a seed packet header 444 that contains 

information concerning the number of seeds to follow. As 
shown, the seed packet header 444 contains a count for each 
type of service. As described above, a different seed is 
used to encrypt each service. Essentially, therefore, the 

15 seed packet header 444 specifies the number of each type of 
service carried in the multiplex. For example, a video seed 
count 44 6 provides a count of the number of video services 
carried in the multiplex data stream. With this 
information, the service demultiplexer in a given decoder 

20 knows how many video service seeds will follow. Similarly, 

an audio seed count 44 8 indicates the number of audio service 
seeds to follow. Twenty-one bits (i.e., field 452) are 
reserved for future use in the event that other types of 
services are encrypted. For example, if teletext data were 

25 to be encrypted, a count would be added to the seed packet 
header 444 indicating how many seeds would follow for that 
service. 

After the seed packet header, the remainder of the 
first packet 440 contains the actual seed values. As shown, 

30 the seeds are simply provided consecutively by service type. 
If all the required seeds do not fit within the first seed 
packet, another seed packet may be provided on a subsequent 
line. Figure 20 illustrates an exemplary seed packet that 
would follow on the next line of a given field of the 

35 multiplex and would carry the remainder of the seeds. In the 
example shown in Figures 19 and 20, there are 10 video 
services being carried in the multiplex. Consequently, the 
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video seed count 446 in the seed packet header 444 of the 
first SSP 44 0 will indicate that 10 video service seeds are 
to follow. As shown, only eight of the video service seeds 
fit within the first SSP 44 0. The video service seeds are 
5 arranged consecutively within the SSP and are shown generally 
at 456 in Figure 19. Figure 20 illustrates the contents and 
arrangement of a subsequent SSP that preferably will be 
transmitted on the line immediately following the line 
containing the first SSP 440 of Figure 19. As shown, the 

10 remaining video service seeds (e.g., seeds for video services 
8 thru 10) are arranged consecutively within the subsequent 
SSP 460 followed by the seeds for the audio services, and so 
on. Additional SSPs may be transmitted as needed until all 
the seeds required for service decryption have been 

15 transmitted. It should be noted that alternate seed 

generation methods may be used to reduce the overall amount 
of encryption related information that must be transmitted in 
the SSPs. 

Figure 21 shows the general arrangement and 

2 0 contents of a virtual channel map packet. As explained 

above, the virtual channel map associates a subscriber's "TV 
channel" selection with various services in the multiplex. 
The service demultiplexer in each subscriber's decoder 
interprets the virtual channel map to determine which 
25 services (e.g., video, audio, closed- captioning etc) are 

associated with the subscriber's channel selection, and then 
extracts those services from the multiplex data stream. As 
shown in Figure 21, a virtual channel map packet 470 
comprises a header 472, which identifies the packet as a VCM 

3 0 packet, followed by a plurality of virtual channel 

definitions 474 which, in the preferred embodiment, are each 
230 bits long. A VCM packet, such as packet 470, contains up 
to five virtual channel definitions 474 (labeled 
VCMD1 . . VCMD5) . Each definition comprises a channel number 
35 field 476 that specifies the particular virtual channel 
number being defined, i.e., the number that a subscriber 
would select at the subscriber location. Next, a video 
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assignment field 478 specifies which video service in the 
multiplex data stream corresponds to that virtual channel 
number. Similarly, audio, utility data, and teletext data 
assignments are specified in fields 480, 482 and 484 
5 respectively. As can be seen, virtual channel map 

definitions allow a great degree of flexibility in defining 
the associations between a subscriber's "virtual channel" 
selection and various services within the multiplex data 
stream. A spare field 4 86 is provided for future service 
10 definitions. 

Figure 22 shows the general arrangement and 
contents of an optional system packet that can be transmitted 
in a line of the multiplex data stream. As shown, an 
optional system packet 490 comprises an OSP header 492 and an 
15 OSP data field 494. Optional system packets may contain a 
wide variety of system related information, and as the name 
implies, are optional. 

As explained herein, the system related packets, 
such as SDP, SSPs, VMCPs, VCMs etc., must be transmitted each 
20 cryptocycle. Because these types of packets are too numerous 
to transmit in a single field, they are transmitted over one 
or more of the fields in a cryptocycle. Thus, cryptocycles 
define fixed boundaries in the multiplex data stream 26 
within which a complete set of system related data is 
25 transmitted. Figure 23 illustrates an exemplary cryptocycle. 
More particularly, Figure 23 shows the contents of the 
transport layers (i.e., first thirteen lines) of the eight 
consecutive fields in the exemplary cryptocycle. The example 
shown assumes more than 10 video services are being 
3 0 transmitted, and therefore, two video multiplex control 

packets (VMCPs) are transmitted with every field. In fields 
1, 2 and 4-8, the VMCPs are transmitted on lines 3 and 4 of 
those fields, whereas in field 3, the VMCPs are transmitted 
on lines 11 and 12. Recall that the multiplex map 
3 5 transmitted at the beginning of each field specifies the 
number and location of each of the types of packets 
transmitted within the transport layer of a given field. In 
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the example shown, the virtual channel map definitions are 
transmitted with fields 1 and 2. Service seeds packets are 
all transmitted in field 3. As mentioned, service seeds are 
transmitted one cryptocycle in advance of the data they were 
5 used to encrypt so that the decoder has sufficient time to 
prepare for decryption. It is desirable therefore to 
transmit service seed packets as early in a cryptocycle as 
possible. The remaining fields, 4 through 8, of the 
exemplary cryptocycle of Figure 23 are used for transmitting 
10 teletext data (TT) and addressable data packets (ADPs) , as 
shown: Those skilled in the art will appreciate that the 
type and number of packets transmitted in a given field is 
entirely flexible; the multiplex map can be modified on a per 
field basis to uniquely define the contents of the transport 
15 layer of each field. 

As has been described throughout the specification, 
the general arrangement and contents of a frame of the 
multipl ex data stream (and each of its fields) is dependent 
upon the analog video format being employed at subscriber 
20 locations. Figures 3 through 5 illustrate the arrangement of 
a frame of the multiplex data stream for use with NTSC 
compatible video equipment. Figure 24 shows the general 
arrangement and contents of a frame of the multiplex data 
stream for use with PAL video equipment. The frame is 
25 virtually identical to the NTSC based frame, except that when 
PAL video equipment is being used at subscriber locations, 
the frame has 625 lines. As those skilled in the art will 
appreciate, 625 lines corresponds to the number of lines in 
the analog PAL video format. As explained, according to the 
30 system of the present invention, each line (i.e., 171 bytes) 
of every frame is transmitted at the horizontal line . 
frequency of the particular analog video format being 
employed at subscriber locations. For PAL video, the 
horizontal line frequency F h is 15.625 kHz. Accordingly, the 
35 overall multiplex data rate will be: 

1368 bits x 15.625 kHz = 21.375 Mbps . 
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The overall frame rate will be: 



15 , 625 lines x 
second 



625 lines 



1 Frame 



= 25 frames/s . 



As expected, 25 frames/s is equal to the analog PAL video 
5 frame rate. Although the transmission rate of the multiplex 
data stream for use with PAL compatible video equipment is 
slightly different than the rate used for NTSC equipment, 
those skilled in the art will appreciate that the hardware 
design of the system of the present invention is essentially 
10 the same for both formats; the only difference being that a 
different system clock must be employed in order to generate 
the appropriate clock frequencies used throughout the system. 



each field of the frame of Figure 24. As can be seen, the 

15 general arrangement and contents of the fields shown in 

Figures 25 and 26 for the case of PAL video are essentially 
identical to the arrangement and contents of the fields shown 
in Figure 4 and 5 for the case of NTSC video. The only 
difference is the number of lines in each field. 

20 Because of the flexibility provided by the method 

of the present invention, namely the use of a multiplex map 
to define the contents of each field on a per field basis, 
the system of the present invention is capable of carrying 
HDTV format signals as well. Recall that an HD select field 

25 (see Figure 11) is provided in the multiplex map for 

indicating whether a given field is carrying an HDTV service. 
Figure 27 shows in detail the general arrangement and 
contents of a field of the multiplex data stream for carrying 
a Zenith/AT&T DSC format HDTV signal. HDTV formats naturally 

30 require a higher data rate than normal NTSC video data, and 
therefore, only one HDTV service can be carried in a single 
multiplex data stream. Because only one service is being 
transmitted, the number and types of data packets in the 
transport layer of each field can be reduced. As shown in 

35 Figure 2, when the Zenith/AT&T DSC-HDTV format is being 

carried, the transport layer may comprise a maximum of five 
lines of each field after the VSYNC word. Other HDTV formats 



Figures 25 and 26 illustrate further details of 
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may alter the amount of lines that can be used for transport 
layer information. 

As can be seen from Figure 27, the HSYNC and offset 
byte are the same whether transporting HDTV, NTSC or PAL 
5 compatible video services. A main difference in the HDTV 
based field depicted in Figure 27, however, is the manner in 
which audio services are provided within the field. Most 
HDTV format definitions specify how audio data is to be 
carried. Figure 27 illustrates how audio is carried in the 
10 Zenith/AT&:T DSC format. 

As the foregoing illustrates, the present invention 
comprises a system and method for transmitting a plurality of 
digital services to a plurality of remote locations. Great 
flexibility is achieved by allocating portions of each field 
15 of the multiplex data stream to the various services and by 
transmitting a multiplex map with each field that specifies 
how the data space within the field is allocated. With the 
multiplex map, the amount of system overhead carried within 
each field of the multiplex data stream may be tailored to 
20 the particular number of services being carried. In 

addition, according to another aspect of the system and 
method of the present invention, data rates within the system 
are related to corresponding analog video frequencies of the 
analog video equipment being used with the system. The 
25 relation to analog video frequencies simplifies hardware 

design in that standard analog video circuitry may easily be 
employed in the decoders at each subscriber location and all 
clock frequencies required throughout the system, including 
digital and analog frequencies, may be derived from a base 
3 0 frequency using suitable phase- lock- loops and frequency 

dividers and multipliers. It will be appreciated by those 
skilled in the art that changes could be made to the 
embodiments described above without departing from the broad 
inventive concepts thereof. It is understood, therefore, 
3 5 that this invention is not limited to the particular 
embodiments disclosed, but is intended to cover all 
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modifications which are within the scope and spirit of the 
invention as defined by the appended claims . 
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WHAT IS CLAIMED IS: 

1. In a communications system, a method of 
transmitting a plurality of digital services from an 
origination point to at least one remote location, said 
method comprising the steps of: 

(a) multiplexing said plurality of digital 
services in a time-division manner to form a multiplexed data 
stream, said multiplexed data stream having a format 
comprising a continuous sequence of fields, different 
portions of each field being allocated to different ones of 
said services; 

(b) generating, for each field, a multiplex map 
that at least indirectly specifies which portions of the 
field are allocated to which services, and inserting the 
multiplex map in the multiplex data stream at the beginning 
of the field; and 

(c) transmitting the multiplex data stream to at 
least one remote location. 

2 . A method according to claim 1 wherein each 
20 digital service has a respective data rate, and wherein the 
size of the portion of each field allocated to a particular 
service is related to the data rate of said service . 

3 . A method according to claim 1 wherein each 
digital service has a respective data rate, and wherein said 
25 portions of each field are allocated to said services in 
proportion . to the respective data rates of each service* 

4 . A method according to claim 2 further 
comprising the step of adjusting, on a per field basis, the 
size of the portions allocated a particular service as the 

30 data rate of that service changes. 

5 . A method according to claim 1 wherein some of 
said digital services are video services to be transformed at 
said remote location into an analog video format, and wherein 



10 
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the format of each field of the multiplex data stream is 
related to a corresponding analog field format of said analog 
video format . 

6 . A method according to claim 1 wherein the 

5 format of each field of the multiplex data stream comprises a 
plurality of successive lines each containing a pre- 
determined number of bits, and wherein step (c) comprises 
transmitting successive lines of each field at a rate 
substantially equal to a horizontal line frequency of said 
10 analog video format. 

7 . A method according to claim 1 wherein each 
field has a format comprising a predetermined number of 
successive lines each containing a pre -determined number of 
bits, a first group of successive lines defining a transport 

15 layer region of said field, and a second group of successive 
lines defining a service data region. 

8 . A method according to claim 7 wherein the 
first line of each field contains a field synchronization 
word (VSYNC) and the lines of the transport layer region 

20 immediately follow said first line, and further wherein step 
(b) comprises inserting the multiplex map for each field in a 
first line of the transport layer region of that field. 

9 . A method according to claim 7 wherein said 
portions of each field that are allocated to said services 

25 are located within said service data region of each field, 
and wherein said transport layer region contains system 
related data packets including packets of the following 
types: system data packets (SDPs) , addressable data packets 
(ADPs) , virtual channel map packets (VCMPs) , service seed 

30 packets (SSPs) , and teletext packets (TTs) , the multiplex 
maps generated for each field further specifying the number 
and location of each system related data packet contained in 
the transport layer region of that field. 
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10 . A method according to claim 7 wherein said 
portions of each field that are allocated to said digital 
services are located within said service data region of each 
field, and wherein at least some of said digital services 

5 comprise digital video services, and further wherein a 

portion of said service data region of each field comprises a 
video service data portion, said video service data portion 
comprising a plurality of video data packets each comprising 
a same number of bits, different bits of each video data 
10 packet being allocated to different ones of said digital 
video services . 

11. A method according to claim 10 wherein each 
digital service has a respective data rate, and wherein the 
bits of each video data packet are allocated among said 

15 digital video services in proportion to the respective data 
rates of each service. 

12 . A method according to claim 11 wherein for a 
particular field, the allocation of bits within each video 
data packet is identical, said method further comprising 
performing the following additional steps for each field: 

(i) generating at least one video multiplex 
control packet that specifies which bits in each video data 
packet are allocated to which digital video services; and 

(ii) inserting said video multiplex control packet 
in the transport layer region of said field prior to 
transmitting that field of the multiplex data stream in step 
(c) . 

13 . A method according to claim 12 wherein the 
multiplex map generated for each field, further specifies the 

30 location of the video multiplex control packet inserted in 
the transport layer region of that field, said multiplex map 
thereby indirectly specifying which portions of each video 
data packet are allocated to which video services . 
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14 . A method according to claim 7 further 
comprising the step of independently encrypting, prior to 
performing step (a) , each of said digital services in 
accordance with an encryption algorithm upon said encryption 

5 algorithm being keyed with a seed value unique to that 

service, and inserting the unique seed value for each service 
in the transport layer region of at least one of said fields 
for transmission to the remote location* 

15 . A method according to claim 14 further 

10 comprising the step of further encrypting, after performing 
step (a) , selected portions of each field in accordance with 
said encryption algorithm upon said encryption algorithm 
being keyed by a global seed. 

16. A method according to claim 15 further 

15 comprising the step of periodically changing the global seed 
and the unique seed values used to encrypt each service . 

17. In a communications system, a method of 
transmitting a plurality of digital services from an 
origination point to at least one remote location, at least 

20 some of said digital services comprising digital video 
services, said method comprising the steps of: 

(a) multiplexing said digital services in a time- 
division manner to form a multiplexed data stream having a 
format comprising a continuous sequence of fields, each field 

25 comprising a predetermined number of successive lines, a 
first group of successive lines in each field defining a 
transport layer region of that field, and a second group of 
successive lines in each field defining a service data region 
of that field, at least one portion of said service data 

3 0 region of each field defining a video service data portion 

comprising a plurality of video data packets, each video data 
packet comprising a pre -determined number of bits, different 
bits of each video data packet being allocated to different 
ones of said digital video services, other portions of said 
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service data region being allocated to other ones of said 
digital services; 

(b) generating, for each field, at least one video 
multiplex control packet that specifies which bits of each 

5 video data packet in that field are allocated to which of 
said digital video services; 

(c) generating a plurality of system related data 

packets ; 

(d) inserting in the transport layer region of 

10 each field, the video multiplex control packet generated in 
step (b) for that field, and a selected group of the system 
related data packets generated in step (c) ; 

(e) generating, for each field, a multiplex map 
that specifies the number and location of each video 

15 multiplex control packet and system related data packet 
inserted in the transport layer region of that field, and 
inserting the multiplex map in a first line of said transport 
layer region; and 

(f ) transmitting the multiplex data stream to at 
20 least one remote location. 



18 . A method according to claim 17 wherein the 
system related data packets include packets of the following 
types: system data packets (SDPs) , addressable data packets 
(ADPs) , virtual channel map packets (VCMPs) , service seed 

25 packets (SSPs) , and teletext packets (TTs) , and further 

wherein the number and type of system related data packets 
inserted into each field in step (c) may differ from field to 
field. 

19 . A method according to claim 17 wherein each 

3 0 digital video service has a respective data rate, and wherein 
the number of bits of each video data packet allocated to a 
particular service is related to the data rate of said 
service . 
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20. A method according to claim 17 wherein each 
digital service has a respective data rate, and wherein the 
bits of each video data packet are allocated among said 
digital video services in proportion to the respective data 

5 rates of each service . 

21. A method according to claim 17 wherein said 
digital video services are to be transformed at said remote 
location into an analog video format, and wherein the number 
of lines in each field of the multiplex data stream is 

10 substantially equal to the number of lines in a corresponding 
field of said analog video format . 

22. A method according to claim 17 wherein said 
digital video services are to be transformed at said remote 
location into an analog video format, and wherein step (f) 

15 comprises transmitting successive lines of each field at a 
rate substantially equal to a horizontal line frequency of 
said analog video format . 

23. In a communications system, a method of 
transmitting a plurality of digital services from an 

2 0 origination point to at least one remote location, said 

method comprising the steps of : 

(a) multiplexing said plurality of digital 
services in a time-division manner to form a multiplexed data 
stream, said multiplexed data stream having a format 
25 comprising a continuous sequence of fields, each field 
comprising a predetermined number of successive lines, a 
first group of successive lines in each field defining a 
transport layer region of that field and a second group of 
successive lines in each field defining a service data region 

3 0 of that field, different portions of the service data region 

of each field being allocated to different ones of said 
digital services, at least some of said services comprising 
digital video services to be transformed at the remote 
location into an analog video format; and 
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(c) transmitting successive lines of each field to 
the remote location at a rate substantially equal to a 
horizontal line frequency of said analog video format. 

24. A method according to claim 23 further 
5 comprising the steps of: 

(i) generating, for each field, a multiplex map 
that at least indirectly specifies which portions of the 
service data region of that field are allocated to which of 
said digital services; and 
10 (ii) inserting the multiplex map for each field in 

a first line of the transport layer region of that field. 

25. A method according to claim 23 wherein each 
digital service has a respective data rate, and wherein the 
size of the portion of the service data region of each field 
allocated to a particular digital video service is related to 
the data rate of said service . 

26. A method according to claim 25 further 
comprising the step of adjusting, on a per field basis, the 
sizes of the portions allocated to each service as the 
respective data rates of each digital service change. 

27. A method according to claim 23 wherein each 
digital service has a respective data rate, and wherein the 
portions of the service data region of each field are 
allocated to said services in proportion to the respective 

25 data rates of each service. 

28. A method according to claim 23 wherein the 
pre-determined number of successive lines in each field of 
the multiplex data stream is substantially equal to the 
number of analog video lines in a corresponding field of said 

30, analog video format. 

29. A method according to claim 23 wherein a first 
line of each field contains a field synchronization word 
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(VSYNC) and wheirein a first portion of each line contains a 
line synchronization byte (HSYNC) , and further wherein a last 
portion of each line of the transport layer and service data 
regions comprises a block error code generated from the 
5 remaining portion of the line in accordance with a block 
error coding scheme . 

30. A method according to claim 23 wherein in 
addition to said digital video services, at least some of 
said digital services comprise digital audio services, and 

10 wherein a first portion of each line of the service data 
region of each frame contains a multiplexed combination of 
bits from each of said digital audio services, and wherein a 
second portion of each line of the service data region 
comprises a plurality of video data packets each containing a 

15 multiplexed combination of bits from each of said digital 
video services, the bits of each video data packet being 
allocated among said video services in proportion to 
respective data rates of each service. 

31. A method according to claim 3 0 further 

2 0 comprising performing the following additional steps for each 
field: 

(i) generating at least one video multiplex 
control packet that specifies which bits in each video data 
packet are allocated to which digital video services; and 
25 (ii) inserting said video multiplex control packet 

in the transport layer region of said field prior to 
transmitting the lines of that field in step (b) . 

32. In a communications system, a method of 
transmitting a plurality of digital video services from an 

30 origination point to at least one remote location, each of 
said digital video services having a respective data rate, 
said method comprising the steps of: 

(a) multiplexing said plurality of digital video 
services in a time-division manner to form a multiplexed data 
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stream, said multiplexed data stream having a format 
comprising a continuous sequence of fields, a first portion 
of each field defining a transport layer region and a second 
portion defining a service data region, different portions of 
5 the service data region of each field being allocated to 
different ones of said digital video services in proportion 
to the respective data rates of each service such that the 
size of the portion allocated to a particular service is 
related to the data rate of that service; 

10 (b) for each field, generating at least one video 

multiplex control packet that specifies which portions of the 
service data region are allocated to which services, and 
inserting the video multiplex control packet in the transport 
layer region of that field; and 

15 (c) transmitting successive fields of the 

multiplex data stream to the remote location. 

33 . A method according to claim 32 further 
comprising the step of adjusting, on a per field basis, the 
size of the portions of the service data region allocated to 
20 each of said video services as the data rates of said video 
services change. 



34 . A method of decoding a multiplexed data stream 
received at a remote location, wherein said multiplexed data 
stream contains a multiplexed combination of digital services 

25 and has a format comprising a plurality of fields, different 
portions of each field being allocated to different ones of 
said digital services, each field having a multiplex map 
located at the beginning of the field containing information 
that at least indirectly specifies which portions of the 

3 0 field are allocated to which of said digital services, said 
method comprising the steps of: 

(a) receiving successive fields of the multiplex 
data stream at the remote location; 

(b) selecting a digital service for extraction 
35 from said received multiplex data stream; 
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(c) for each successive field: 

(i) recovering the multiplex map from the 
beginning of the field and identifying, based at least in 
part upon the information contained therein, which portion of 

5 the field is allocated to the selected service; and 

(ii) extracting from the field the portion 
identified in step (c) (i) ; and 

(d) combining the portions extracted from each 
successive field to reconstruct the selected service at the 

10 remote location. 

35. A method of decoding a multiplexed data stream 
received at a remote location, wherein said multiplexed data 
stream contains a multiplexed combination of digital services 
at least some of which are digital video services, and 

15 wherein said multiplexed data stream has a format comprising 
a continuous sequence of fields, each field comprising a 
predetermined number of successive lines, a first group of 
successive lines in each field defining a transport layer 
region of that field, and a second group of successive lines 

20 in each field defining a service data region of that field, 

at least one portion of said service data region of 
each field defining a video service data portion comprising a 
plurality of video data packets, different portions of each 
video data packet being allocated to different ones of said 

25 digital video services, 

said transport layer region of each field 
containing a video multiplex control packet comprising 
information that specifies, for that field, which portions of 
each video data packet in that field are allocated to which 

3 0 of said digital video services, and a multiplex map located 
in a first line of said transport layer region comprising 
information that specifies the location, within the transport 
layer region, of at least said video multiplex control 
packet , 

3 5 said method comprising the steps of: 
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(a) receiving successive fields of the multiplex 
data stream at the remote location; 

(b) selecting a digital video service for 
extraction from said received multiplex data stream; 

5 (c) for each successive field: 

(i) recovering the multiplex map from the 
beginning of the transport layer region of that field; 

(ii) locating and recovering the video 
multiplex control packet from the transport layer based upon 

10 the information contained in the recovered multiplex map; 

(iii) identifying, based upon the information 
contained in the recovered video multiplex control packet, 
which portion of each video data packet of said field is 
allocated to the selected digital video service; and 

15 (iv) extracting the identified portion from 

each of the video data packets in that field; and 

(d) combining the portions extracted from each 
successive field in step (c) (iv) to reconstruct the selected 
video service at the remote location. 

20 36. An encoder apparatus for use in a 

communications system, said encoder apparatus being connected 
to receive a plurality of digital services for generating a 
multiplexed data stream comprising said digital services, 
said multiplexed data stream having a format comprising a 

25 continuous sequence of fields, different portions of each 
field being allocated to different ones of said services, 
said encoder comprising: 

a control computer for generating a multiplex map 
for each field that at least indirectly specifies which 

3 0 portions of the field are to be allocated to which of said 
digital services; 

a field builder coupled to the control computer and 
coupled to receive said digital services, said field builder 
being operative to construct each successive field of the 

3 5 multiplex data stream in accordance with the multiplex map 
generated for that field by the control computer, said field 
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builder being further operative to insert each multiplex map 
in its respective field; and 

a transmitter coupled to the field builder for 
transmitting successive fields of the multiplex data stream. 

5 37. An encoder apparatus according to claim 36 

wherein each digital service has a respective data rate, and 
wherein the size of the portion of each field allocated to a 
particular service is related to the data rate of said 
service . 

10 38. An encoder apparatus according to claim 36 

wherein each digital service has a respective data rate, and 
wherein said portions of each field are allocated among said 
services in proportion to the respective data rates of each 
service. 

15 39. An encoder apparatus according to claim 3 7 

wherein said control computer is further operative to adjust, 
on a per field basis, the size of the portions allocated to 
each service as the data rates of said digital services 
change . 

2 0 40. An encoder apparatus according to claim 3 6 

wherein some of said digital services are video services to 
be transformed at said remote location into an analog video 
format, and wherein the format of each field of the multiplex 
data stream is related to a corresponding analog field format 

2 5 of said analog video format. 

41. An encoder apparatus according to claim 36 
wherein some of said digital services comprise digital video 
services to be transformed at said remote location into an 
analog video format, and further wherein the format of each 
30 field of the multiplex data stream comprises a plurality of 
successive lines each containing a pre -determined number of 
bits, and wherein the transmitter transmits successive lines 
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of each field at a rate substantially equal to a horizontal 
line frequency of said analog video format . 



42. An encoder apparatus according to claim 3 6 
wherein each field has a format comprising a predetermined 

5 number of successive lines each containing a pre-determined 
number of bits, a first group of successive lines defining a 
transport layer region of said field and a second group of 
successive lines defining a service data region. 

43 . An encoder apparatus according to claim 42 
10 further comprising means for inserting a field 

synchronization word (VSYNC) in a first line of each field, 
said transport layer region comprising a first group of lines 
following said first line of the field, said frame builder 
being operative to insert the multiplex map for each field in 
15 a first line of the transport layer region of that field such 
that the multiplex map immediately follows the field 
synchronization word (VSYNC) . 

44 . An encoder apparatus according to claim 42 
wherein the control computer is further operative to 

20 construct a plurality of system related data packets 
including system data packets (SDPs) , addressable data 
packets (ADPs) , virtual channel map packets (VCMPs) , service 
seed packets (SSPs) , and teletext packets (TTs) , said field 
builder inserting selected ones of said system related data 

25 packets in the transport layer regions of each successive 
field, the multiplex map generated for each field further 
specifying the number and location of each system related 
data packet contained in the transport layer region of that 
field. 

3 0 45. An encoder apparatus according to claim 4 2 

wherein at least some of said digital services comprise 
digital video services, and wherein said encoder apparatus 
further comprises: 
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a video service multiplexer coupled to receive said 
digital video services for multiplexing said digital video 
services in a time -division manner to produce a plurality of 
video data packets, different portions of each video data 
packet being allocated to a different one of said digital 
video services, 

said field builder being coupled to the video 
service multiplexer for inserting a number of successive 
video data packets in the service data region of each field 
of the multiplex data stream, 

said control computer being further operative to 
generate a video multiplex control packet for each field that 
specifies, for each video data packet in that field, which 
portions of each video data packet are allocated to which 
digital video services, said field builder being further 
operative to insert the video multiplex control packet in the 
transport layer region of that field in a location specified 
by the multiplex map for that field. 

46. An encoder apparatus according to claim 45 
2 0 wherein each digital video service has a respective data 

rate, and wherein the portions of each video data packet are 
allocated among said digital video services in proportion to 
the respective data rates of each service. 

47. An apparatus according to claim 42 further 
25 comprising: 

a seed generator for generating a unique encryption 
seed for each of said digital services ; 

a plurality of data encryptors each coupled to the 
seed generator and each coupled to receive a different one of 
30 said digital services for encrypting that digital service in 
accordance with an encryption algorithm upon said encryption 
algorithm being keyed with the unique encryption seed 
generated for that service, 

said field builder being further operative to 
35 insert the unique seed values for each service in the 
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transport layer region of at least one of said fields prior 
to t r ansmi s s ion . 

48. An encoder apparatus according to claim 4 7 
further comprising a global encryptor for further encrypting 
5 selected portions of each field in accordance with said 
encryption algorithm upon said encryption algorithm being 
keyed by a global seed, said field builder being further 
operative to insert the global seed in the transport layer 
region of at least one field. 

10 49. An encoder apparatus for use in a 

communications system, said encoder apparatus being connected 
to receive a plurality of digital services for generating a 
multiplexed data stream comprising said digital services, at 
least some of said digital services comprising digital video 

15 services, said multiplexed data stream having a format 
comprising a continuous sequence of fields, each field 
comprising a predetermined number of successive lines, a 
first group of successive lines in each field defining a 
transport layer region containing a plurality of system 

20 related data packets, and a second group of successive lines 
in each field defining a service data region of that field, a 
portion of the service data region defining a video data 
portion comprising a plurality of video data packets, 
different portions of each video data packet being allocated 

25 to different ones of said digital video services, said 

transport layer region of each frame further containing at 
least one video multiplex control packet and a multiplex map 
that contains information specifying the number and location 
of each video multiplex control packet and system related 

3 0 data packet contained in the transport layer region of that 
field, said encoder apparatus comprising: 

a control computer for generating said video 
multiplex control packets, multiplex maps and system related 
data packets; 
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a video service multiplexer coupled to receive said 
digital video services and responsive to said video multiplex 
control packets for multiplexing said digital video services 
in a time-division manner to produce said video data packets, 
5 each video multiplex control packet determining, for its 
respective field, which bits of each video data packet in 
that field are allocated to which video services; 

a field builder coupled to the control computer and 
to the video service multiplexer for constructing each field 
10 in accordance with the information contained in the multiplex 
map generated by the control computer for that field; and 

a transmitter for transmitting successive fields of 
the multiplex data stream to a remote location . 

50. An encoder apparatus according to claim 4 9 

15 wherein some of said digital services are video services to 
be transformed at said remote location into an analog video 
format, and wherein the predetermined number of lines in each 
field of the multiplex data stream is substantially equal to 
the number of analog video lines in a corresponding field of 

20 said analog video format. 

51. An encoder apparatus according to claim 49 
wherein some of said digital services are video services to 
be transformed at said remote location into an analog video 
format, and wherein the transmitter transmits successive 

25 lines of each field at a rate substantially equal to a 
horizontal line frequency of said analog video format. 

52. An encoder apparatus according to claim 49 
wherein each digital video service has a respective data 
rate, and wherein the portions of each video data packet are 

3 0 allocated among said digital video services in proportion to 
the respective data rates of each service. 

53. An apparatus according to claim 49 further 
comprising : 
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a seed generator for generating a unique encryption 
seed for each of said digital services; 

a plurality of data encryptors each coupled to the 
seed generator and each coupled to receive a different one of 
5 said digital services for encrypting that digital service in 
accordance with an encryption algorithm upon said encryption 
algorithm being keyed with the unique encryption seed 
generated for that service, 

said field builder being further operative to 
10 inserting the unique, seed values for each service in the 

transport layer region of at least one of said fields prior 
to transmission. 



54 . An encoder apparatus according to claim 53 
further comprising a global encryptor for further encrypting 
15 selected portions of each field in accordance with said 
encryption algorithm upon said encryption algorithm being 
keyed by a global seed, said field builder being further 
operative to insert the global seed in the transport layer 
region of at least one field. 

20 55. A decoder apparatus for use at a remote 

location to decode a multiplexed data stream received at that 
location, wherein said multiplexed data stream contains a 
multiplexed combination of digital services and has a format 
comprising a plurality of fields, different portions of each 

25 field being allocated to different ones of said digital 

services, each field having a multiplex map located at the 
beginning of the field containing information that at least 
indirectly specifies which portions of the field are 
allocated to which of said digital services, said decoder 

30 apparatus comprising: 

a receiver for receiving successive fields of the 
multiplex data stream; 

a data extractor for locating and extracting the 
multiplex map from a received field of the multiplex data 

35 stream; 
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a selector for selecting at least one of said 
digital services for extraction from said received 
multiplexed data stream; and 

a service data demultiplexer responsive to the 
5 extracted multiplex map for identifying, based at least in 
part upon information contained in the multiplex map, the 
portion of the received field allocated to the selected 
service, and for extracting the identified portion from the 
received field, 

10 whereby the portions extracted from successive 

fields may be combined to reconstruct the selected service. 

56. A decoder apparatus for use at a remote 
location to decode a multiplex data stream received at that 
location, wherein said multiplexed data stream comprises a 
15 plurality of multiplexed digital services, at least some of 
said digital services comprising digital video services, said 
multiplexed data stream having a format comprising a 
continuous sequence of fields, each field comprising a 
predetermined number of successive lines, a first group of 

2 0 successive lines in each field defining a transport layer 

region containing a plurality of system related data packets, 
and a second group of successive lines in each field defining 
a service data region of that field, a portion of the service 
data region defining a video data portion comprising a 
25 plurality of video data packets, different portions of each 
video data packet being allocated to different ones of said 
digital video services, said transport layer region of each 
field further containing (i) at least one video multiplex 
control packet that specifies which portions of each video 

3 0 data packet within that field are allocated to which digital 

video services and (ii) a multiplex map that specifies the 
number and location of each video multiplex control packet 
and system related data packet contained in the transport 
layer region of that field, said decoder apparatus 
3 5 comprising: 
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a receiver for receiving successive fields of the 
multiplex data stream; 

a selector for selecting one of said digital video 
services for extraction from said received multiplexed data 
5 stream; 

a multiplex map extractor for extracting the 
multiplex map from the transport layer region of a received 
field; 

a transport layer demultiplexer coupled to the 
10 multiplex map extractor and responsive to the extracted 

multiplex map for locating and extracting the video multiplex 
control packet contained in the transport layer region of the 
received field; and 

a video service demultiplexer responsive to the 
15 extracted video multiplex control packet for identifying, 
based upon information contained in the video multiplex 
control packet, which portion of each video data packet in 
the service data region of the received field is allocated to 
the selected service, and for extracting the identified 
20 portion from each video data packet, 

whereby the portions extracted from successive 
fields may be combined to reconstruct the selected video 
service . 

57. A method of formatting a serial bit stream for 
25 carrying a multiplexed combination of data from each of a 
plurality of digital services, said method comprising the 
steps of: 

(a) partitioning the serial bit stream into a 
continuous sequence of fields; 
30 (b) allocating different portions of each field to 

different ones of said digital services such that each 
portion contains data of a different one of said services; 
and 

(c) for each field, (i) generating a multiplex map 
35 that specifies, at least indirectly, which portions of the 
field are allocated to which of said digital services, and 
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(ii) inserting the multiplex map at the beginning of that 
field. 

58. A method according to claim 57 wherein each 
digital service has a respective data rate, and wherein the 

5 size of the portion of each field allocated to a particular 
service is related to the data rate of said service. 

59. A method according to claim 57 wherein each 
digital service has a respective data rate, and wherein said 
portions of each field are allocated to said services in 

10 proportion to the respective data rates of each service. 

60. A method according to claim 58 further 
comprising the step of adjusting, on a per field basis, the 
sizes of the portions allocated to each service as the 
respective data rates of each service change . 

15 61. A method according to claim 57 wherein each 

field comprises a predetermined number of successive lines 
each containing a predetermined number of bits, and wherein 
some of said digital services are video services to be 
transformed at a remote location into an analog video format, 

20 and further wherein the predetermined number of successive 
lines in each field is substantially equal to the number of 
analog video lines in a corresponding field of said analog 
video format . 



62. A method according to claim 57 wherein each 
25 field comprises a predetermined number of successive lines 

each containing a predetermined number of bits, a first group 
of successive lines defining a transport layer region of said 
field, and a second group of successive lines defining a 
service data region. 



DOCID: <WO. 



9410775A1 I > 



WO 94/10775 



PCT/US93/1049J 



- 67 - 

63. A method according to claim 62 further 
comprising the step of inserting a field synchronization word 
(VSYNC) in a first line of each field. 

64 . A method according to claim 63 wherein for 

5 each field, the group of lines defining the transport layer 
region of that field follow immediately after the first line 
and step (c) (ii) comprises inserting the multiplex map for 
that field in a first line of the transport layer region of 
that field such that the multiplex map follows immediately 
10 after the field synchronization word. 

65. A method according to claim 62 further 
comprising the step of inserting a plurality of system 
related data packets in the transport layer region of each 
field, and wherein for each field, step (c) (ii) comprises 

15 inserting the multiplex map for that field in a first line of 
the transport layer region, said multiplex map specifying the 
number and location of each system related data packet 
inserted in the transport layer region. 

66. A method according to claim 62 wherein at 

2 0 least some of said digital services comprise digital video 

services, and wherein a portion of said service data region 
of each field defines a video data portion, and further 
wherein step (b) comprises performing the following steps for 
each field: 

25 (i) partitioning the video data portion into a 

plurality of video data packets each comprising a same number 
of bits; 

(ii) allocating different portions of each video 
data packet to different ones of said digital video services; 

3 0 and 

(iii) allocating other portions of the service 
•data region to other ones of said digital services. 
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67. A method according to claim 66 wherein each 
digital service has a respective data rate, and wherein step 
(b) (ii) comprises allocating the different portions of each 
video data packet among said digital video services in 

5 proportion to the respective data rates of said digital video 
services . 

68. A method according to claim 67 wherein for a 
particular field, the allocation of bits within each video 
data packet is identical, said method further comprising 

10 performing the following steps after step (b) but prior to 
step (c) : 

(a') generating at least one video multiplex 
control packet that specifies which portions of each video 
data packet in that field are allocated to which digital 
15 video services; and 

(b') inserting the video multiplex control packet 
in the transport layer region of the field, the multiplex map 
generated in step (c) (i) specifying the location of said 
video multiplex control packet within the transport layer 

2 0 region, said multiplex map thereby indirectly specifying 

which portions of each video data packet are allocated to 
which video services. 

69. A method of generating a serial bit stream 
containing a multiplexed combination of data from each of a 

25 plurality of digital services, at least some of said digital 
services comprising digital video services, said method 
comprising the steps of: 

(a) defining a continuous sequence of fields in 
the bit stream, each field comprising a predetermined number 

3 0 of consecutive lines; 

(b) defining a first group of lines in each field 
as a transport layer region of that field, and defining a 
second group of lines as a service data region; 

(c) further defining at least a portion of the 

3 5 service data region of each field as a video data portion, 
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and partitioning the video data portion into a plurality of 
video data packets; and 

(d) performing the following additional steps for 
each field: 

5 (i) allocating different portions of each 

video data packet in the field to different ones of said 
digital video services such that each portion of each video 
data packet contains data of a different one of said digital 
video services ; 

10 (ii) generating a video multiplex control 

packet that specifies which portions of each video data 
packet in the field are allocated to which digital video 
services, and inserting the video multiplex control packet in 
the transport layer region of the field; and 

15 (iii) generating a multiplex map that at 

least specifies the location of said video multiplex control 
packet within the transport layer region, and inserting the 
multiplex map in a first line of said transport layer region. 



70. A method according to claim 69 wherein at 
least some of said digital video services are to be 
transformed at a remote location into an analog video format, 
and wherein the predetermined number of successive lines in 
each field is substantially equal to the number of analog 
video lines in a corresponding field of said analog video 
format . 

71. A method according to claim 69 further 
comprising the step of inserting a field synchronization word 
(VSYNC) in a first line of each field. 

30 72. A method according to claim 69 further 

comprising the step of inserting a plurality of system 
related data packets in the transport layer region of each 
field prior to performing step (d) (iii) , and wherein the 
multiplex map generated in step (d) (iii) further specifies 
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the location of each system related data packet inserted in 
the transport layer region. 

73. A method according to claim 69 wherein each 
digital video service has a respective data rate, and wherein 

5 the portions of each video data packet are allocated among 
said digital video services in proportion to the respective 
data rates of each digital video service. 

74 . A method according to claim 73 further 
comprising the step of adjusting, on a per field basis, the 

10 sizes of the portions allocated to each service as the 
respective data rates of each service change. 

75. A digital signal format for multiplexing a 
plurality of digital serviced into a serial bit stream, said 
format comprising a continuous sequence of fields, different 
portions of each field being allocated to different ones of 
said digital services such that each portion may contain data 
for a different one of said services, each field containing, 
at a beginning thereof, a multiplex map that at least 
indirectly specifies which portions of the field are 
allocated to which of said digital services. 

76. A digital signal format according to claim 75 
wherein each field comprises a predetermined number of 
successive lines, and wherein a first group of successive 
lines in each field defines a transport layer region for 

25 inserting a plurality of system related data packets, and 
wherein a second group of successive lines in each field 
defines a service data region. 

77. A digital signal format according to claim 76 
wherein at least some of said digital services comprise 

3 0 digital video services, and wherein a portion of the service 
data region of each field defines a video data portion, and 
further wherein said video data portion is partitioned into a 
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plurality of video data packets, different portions of each 
video data packet being allocated to different ones of said 
digital video services . 

78 . A digital signal format according to claim 77 
5 wherein the transport layer region of each field contains at 

least one video multiplex control packet that specifies which 
portions of each video data packet in that field are 
allocated to which digital video services, and wherein the 
multiplex map in each field specifies the location of each 
10 video multiplex control packet in the transport layer region 
of that field. 

79. A digital signal format according to claim 77 
wherein each of said digital video services has a respective 
data rate, and wherein the portions of each video data packet 

15 are allocated among said digital video services in proportion 
to the respective data rates of said digital video sources . 

80. A digital signal format according to claim 76 
wherein at least some of said digital video services are to 
be transformed to an analog video format at a remote 

2 0 location, and further wherein the predetermined number of 

successive lines in each field is substantially equal to the 
number of analog video lines in a corresponding field of said 
analog video format . 

81. A digital signal format according to claim 76 
25 wherein a first line of each field contains a field 

synchronization word (VSYNC) and wherein a first portion of 
each line contains a line synchronization byte (HSYNC) , and 
further wherein a last portion of each line of the transport 
layer and service data regions comprises a block error code 

3 0 generated in accordance with a block error coding scheme. 

82. A digital signal format according to claim 76 
wherein at least some of said digital services comprise 
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digital audio services, and wherein a first portion of each 
line of the service data region of each field contains a 
multiplexed combination of bits from each of said digital 
audio services. 

5 83 . A digital signal format for multiplexing a 

plurality of digital services into a serial bit stream, at 
least some o # f said digital services comprising digital video 
services, said format comprising: 

a continuous sequence of fields, each comprising a 

10 predetermined number of successive lines, each line 
containing a predetermined number of bits, 

a first group of successive lines in each field 
defining a transport layer region that may contain a 
plurality of system related data packets, 

15 a second group of successive lines in each field 

defining a service data region of that field, 

at least a portion of the service data region 
defining a video data portion that is partitioned into a 
plurality of video data packets, different portions of each 

20 video data packet being allocated to different ones of said 
digital video services, other portions of the service data 
region being allocated to other of said digital services, 

said transport layer region of each field further 
containing (i) at least one video multiplex control packet 

25 that specifies which portions of each video data packet 
within that field are allocated to which digital video 
services and (ii) a multiplex map that specifies the number 
and location of each video multiplex control packet and 
system related data packet contained in the transport layer 

3 0 region of that field. 

84 . A digital signal format according to claim 83 
wherein each of said digital video services has a respective 
data rate, and wherein the portions of each video data packet 
are allocated among said digital video services in proportion 
35 to their respective data rates. 
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85. A digital signal format according to claim 83 
wherein at least some of said digital video services are to 
be transformed to an analog video format at a remote 
location, and further wherein the predetermined number of 

5 successive lines in each field is substantially equal to the 
number of analog video lines in a corresponding field of said 
analog video format . 

86. A digital signal format according to claim 83 
wherein a first line of each field contains a field 

10 synchronization word (VSYNC) and wherein a first portion of 
each line contains a line synchronization byte (HSYNC) , and 
further wherein a last portion of each line of the transport 
layer and service data regions comprises a block error code 
generated in accordance with a block error coding scheme. 

87. A digital signal format according to claim 83 
wherein in addition to said digital video services, at least 
some of said digital services comprise digital audio 
services, and wherein a first portion of each line of the 
service data region of each field contains a multiplexed 
combination of bits from each of said digital audio services. 
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